最小限の環境を作る「フォントえらび」

私は基本、4台のコンピュータを運用している。これはまんま「3部屋+携行」なのだが、それぞれの最終システムインストール日を見ると

  • ThinStation P720 (2019-01)
  • FM2A88X (2017-12)
  • Z400 Workstation (2019-07)
  • ThinkPad X1 Carbon 5thGen (2018-06)

である。ちなみに、これはjournalctlすれば分かる。

システムセットアップ時に悩ましいのがフォントだ。 ここではManjaroを前提にして語るが、日本語フォント関連のパッケージは“font japanese”で検索すると62ほどあり、うち公式パッケージは源ノ角ゴシック、源ノ明朝、IPAフォント、花園明朝、さざなみフォントである。

フォント関連のAURパッケージはあまりメンテナンスされないことが多く、多くのフォントを維持するのはかなり厳しい。インストール時間もかかるので入れるのもしんどい。 ひとつにまとめて、それを/usr/local/share/fontsなどに入れて運用する方法もあるのだが、商用フォントの除外という手間もあるし、OS側(/usr/share/fonts)との兼ね合いもディストリビューションが違ったりすると特に発生しがちなので割と難しい。

なにより、「フォントの数」と「画面の総ピクセル数」は ものすっごく 反応速度に影響するのだ。遅い遅いと思っていたマシンをまっさらにして1366*768なディスプレイをつないだら爆速になったりしている。 だから、メインマシン(もしくはフォントを使うようなアートワーク作業をするマシン)だけにフォントを積んで、他はessentialに運用したい。

ここでは私の経験に基づいてよいと判断したessentialを紹介するが、好みによることはご了承いただきたい。

先に結論

% trizen -S adobe-source-han-sans-jp-fonts adobe-source-han-serif-jp-fonts ttf-cica ttf-ume
  • 商用フォント顔負けのクオリティで出せる源ノ角ゴシック、源ノ明朝
  • zsh-theme-powerlevel9kpowerlineを入れた場合に必要になるpowerlineシンボルなどまでカバーし、日本語コーディングフォントを必要する場合に有用なCica
  • MS日本語フォントにメトリック互換の梅フォント

という構成である。

好みのちょい足し

もう少し意味を補強すると、IPAフォントがあるとLibreofficeで文書をやりとりするようなケースでは有効である。 IPAフォントは公式パッケージなのでインストールしてもいいかもしれない。

さらにいえば、コーディングフォントは日本語フォントである必要はなかったりする。 私が様々なコーディングフォントで様々なコードや文章を書いた経験で言えば、長時間使っていて快適性が高かったコーディングフォントは

  • Hermit
  • Input Mono
  • Fira Mono
  • Meslo
  • Camingo Code
  • Roboto Mono

だった。

あと、私は個人的にMiguも好きなので、

% trizen -S otf-ipafont ttf-migu otf-hermit

好みのちょい盛り

ひょっとしたらスタイリッシュな欧文フォントがないことが不満かもしれない。 定番としてはSenとかだったと思うのだけれど、今SenはGoogle Fontsから外れてしまった。 Overlockも定番。これは個人的には静凛さんのチャット欄がOverlockなので馴染みがある。

ManjaroのロゴフォントであるComfortaaは最近のManjaroはデフォルトで入っていたりする。

あと、Joseffin Sansも好き。

かっこいいSerifフォントが欲しい、とかいうと特に定番はないので、GoogleでSerifカテゴリを選択して探していただくのがよかろう。 Serifフォントに関しては私は商用のHumanist Slab 712を使っていたりするし。 どうしてもお勧めというのであれば、MartelとかCormorant Garamondとか、Abhaya Libreとかだろうか。

そして個人的には源ノ角ゴシックも良いが、やっぱりモトヤフォントが好きだ。 それにこのラインナップでは丸ゴシックがない。

そこで小杉ゴシック小杉丸ゴシックだ。 小杉ゴシックは元「モトヤ Lシーダ W3等幅」、小杉丸ゴシックは「モトヤ Lマルベリ W3等幅」のリネームである。 これらはApache Lisence 2.0でAndroidに載っていたフォントだ。

好みの盛り盛り

ドキュメントを書く上で使いやすいフォントに欠けるので、源暎フォントを追加している。 ただし、これはドキュメント生成、つまりPandocを使う端末のみ。

あと、本文フォントは「源暎ラテミン」よりも「元陽逆アンチック」のほうが人気があるので、それも入れておく

セットアップ

言葉はいらないよな?

<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
        <its:translateRule translate="no" selector="/fontconfig/*[not(self::description)]"/>
    </its:rules>

    <description>Re-define sans-serif, serif and monospace.</description>
    <match target="pattern">
        <test qual="any" name="family">
            <string>sans-serif</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Joseffin Sans</string>
            <string>MotoyaLCedar</string>
            <string>Source Han Sans JP</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>serif</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Overlock</string>
            <string>GenEi Koburi Mincho</string>
            <string>Source Han Serif JP</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>monospace</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Hermit</string>
            <string>Cica</string>
            <string>Migu 1M</string>
        </edit>
        -->
    </match>
</fontconfig>
<?xml version='1.0'?>
<!DOCTYPE fontconfig SYSTEM 'fonts.dtd'>
<fontconfig>
    <its:rules xmlns:its="http://www.w3.org/2005/11/its" version="1.0">
        <its:translateRule translate="no" selector="/fontconfig/*[not(self::description)]"/>
    </its:rules>

    <description>Substitude popular Japanese fonts</description>

    <match target="pattern">
        <test qual="any" name="family">
            <string>MS Pゴシック</string>
        </test>
        <test qual="any" name="family">
            <string>MS PGothic</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume P Gothic S5</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>MS P明朝</string>
        </test>
        <test qual="any" name="family">
            <string>MS PMincho</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume P Mincho</string>
        </edit>
    </match>
    <match target="pattern">
        <test qual="any" name="family">
            <string>MS明朝</string>
        </test>
        <test qual="any" name="family">
            <string>MS Mincho</string>
        </test>
        <edit binding="strong" name="family" mode="prepend">
            <string>Ume Mincho</string>
        </edit>
    </match>
</fontconfig>

Inflatonにおけるサーバープロビジョニングのおはなし

Inflatonにおけるサーバープロビジョニングに関する質問があったので、記事にしようと思う。

基本的にはこの部分は、私の(=Inflatonの)基本的方針を踏襲したものになっている。 つまり、

  • 一般的である、あるいは流行であるということにはとらわれず
  • Unixの流儀に従い
  • 堅牢で確実なツールと手法で
  • 全ての理解が容易であるように

している。

前提

Inflatonにおいては、一般的ではない前提が成り立っている。

まず、「私が前提になっているということ」である。

つまり、私に属人化することは基本的に問題視されない。 それよりも私の能力が発揮できることが優先されるのでやり方は好きに選べる。

もうひとつは、会社自体が少数精鋭になっているということだ。

これを前提に一般的な手法を避けたりもしていて、「IT業界の人間」が直ちに即戦力になるような状況にない。 戦力になるまで、1年くらいは育てて使う方針になっている。

その間賃金が低いとしても、300万円くらいは利益を出さない人のために使うということである。 しかも、まっさらな状態から1年でちゃんとやれるようになるとしたら、つきっきりで教えなくてはならない。 私だとえらいことになってしまうし、全てを教えられるレベルのエンジニアだと年俸600万円は下らないだろう。

これは「1人増えるのが一大イベント」であるからこそできることで、新卒採用があるような会社ではここまでの方法はとれない。

ここまでの前提を以て、他とは違うInflaton styleを可能にしている。

正しい方法

ConoHaの場合、「スタートアップスクリプト」という機能があり、サーバー構成時にスクリプトを実行させることができる。 cloud-config形式とシェルスクリプト形式をサポートしているという。

ConoHaに限らなければ、Chefなどのツールを使うのが一般的である。

もちろん、これらの方法はInflatonでは採用していない。

我々の方法

基本的に

  • ドキュメントを書く
  • シェルスクリプトを書く

の2点である。

ドキュメントは手順書と言っていいのかはわからないが、基本的に最低限コマンドが打てればこれだけ読んで構築できるレベルの内容になっている。 開発も実務も忙しいのに事業かけもちでドキュメントもちゃんと書いていることについては是非とも褒めまくっていただきたい。

シェルスクリプトのほうは、より正確に表現するならZshバッチになっている。 正直なところ、ドキュメントを読むよりもこちらを読むほうがわかりやすいだろう。

何のために、といったことに関しては、そのサービスを構成するものに関する、内部向け外部向けのドキュメントが存在するため、それを見れば確認できる。

それぞれちゃんとした理由がある。

まず、ドキュメントが揃っている最大の理由は、しばらく触ってないソフトウェアやサービスに関して、私が覚えていられないことと、説明する時間が割けないことだ。

弊社取締役はMimir Yokohamaの生徒さんでもあり、私が書くレベルのドキュメントがあればだいたいは理解できる。 このため、ちゃんとドキュメントがあるだけでも私の負担は確実に減る。そして、ドキュメントがなければ私は開発に戻ってくるのが大変になる。

そして、システム構成に関してはあまり固定化されていない。そもそもコンポーネントの変更をしやすいように設計してあり、サーバー面での変更というのは相当カジュアルに行われている。

もちろん、理由は私が管理しているからであるが、もうひとつの理由としてArch Linuxだからというのもある。 Arch Linuxは普通にバージョンも上がれば、役割を担うソフトウェアが変更されることもある。だから、構築から運用を固定化したところで、固定化したものが自動的に通用しなくなって困るだけなのだ。

ドキュメントに関しては単純に都度アップデートしている形だが、実はシェルスクリプトとドキュメントの2段構成にしている大きな理由として、「サーバー構築手順が次のサーバーで成立する可能性はかなり低い」というのがある。 一番躓くのがパッケージ名の変更である。Archは非常にカジュアルにパッケージ名を変更するので、インストールするパッケージ名の指定がコケる原因になる場合が多い。 加えていえば、サーバーソフトウェアの設定ファイルの項目も、意外と頻繁に変わる。

そこで

  1. ドキュメントで手順を確認
  2. そのパートのバッチスクリプトを実行、あるいはドキュメント記載のコマンドをコピペしながら実行
  3. 躓いた場合は原因を確認し、ドキュメントとスクリプトをアップデート

という形でstep by stepで進めていくと構築できるようになっている。 Inflatonとしてはサーバーを増やすのは年に数えるほどでしかないため、完全自動化するのはメリットよりデメリットのほうが大きい。

サーバーインスタンス増加による増強よりは、新しいことをやるために構成の異なるサーバーを立てる頻度のほうが高い。 だから作業においてコアになることが確定している部分…例えばzsh, grml-zsh-config, zsh-theme-powerlevel9k, screenのインストールと、/etc/zshrc.localの設定などはそれでひとつのスクリプトにまとめられている。 なので、このスクリプトは使い回しが効く。

Inflatonでサーバーを立てるということは、最近始まったばかりなので稀な話だが、「システムの構築」そのものは数え切れないくらいやっている。 今でも何らかの理由でシステムを作ることは年に10回くらいはあるし、15年とか前だと週イチなんてペースだったので、知識と経験があるし、効率化も進んでいる。 結局のところ「最適解を追い求めている以上、ゴージャスな方法で固定するよりは変更しやすい方法のほうがいい」というのが教訓なのだ。

ここには私の信念、及び流儀も絡む。 私は「完璧たりうる」と思っているし、かつ「完璧と動的である」と思っている。だからこそ、「完璧を追い求めることにこそ意味がある」と信じている。 そのためには「動いた状態」で固定することには意味がないし、「動的な最善」であるArch Linuxなのである。

一例としては、現在Plutoのサーバーではsshd_config(5)のCiphers

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

である。この設定の主たるところはchacha20-poly1305@openssh.comが外されていることで、外している理由はSSHの処理が比較的重いサービス特性上、サーバー側でAES-NIを使いたいからである。

余談だが、AMDプロセッサはBulldozer以降でAES-NIをサポートしており、IntelはIvy Bridgeまではi3においてAES-NIがサポートされていなかった。 こうしたことを含め、性能の低いデバイスにおいてはAES-NIがなく、計算量の多いAESは重いということになるのだが、コネクションが1本であるクライアントにとっては大した話ではなく、多数のコネクションをさばくサーバー側で軽くすることが優先である。

しかし、この設定ではaes128-ctrが最初に来ており、今後10年で変更されることを意味している。

つまり常に動的に構成され、動的に変更されるのである。 構成時はむしろ構成変更タイミングでもあると言っていい。

手順スクリプトは

pacman -S grml-zsh-config tmux zsh-completions zsh-syntax-highlighting zsh-theme-powerlevel9k zsh-history-substring-search vim vim-plugins rsync
cat > /etc/zshrc.local <<EOF
setopt vi

autoload -U history-search
#zle -N history-beginning-search-backward-end history-search
#zle -N history-beginning-search-forward-end history-search
bindkey "^P" history-beginning-search-backward
bindkey "^N" history-beginning-search-forward
bindkey "\e[5~" history-beginning-search-backward
bindkey "\e[6~" history-beginning-search-forward
bindkey -M viins "\e[5~" history-beginning-search-backward
bindkey -M viins "\e[6~" history-beginning-search-forward
bindkey -M vicmd "\e[5~" history-beginning-search-backward
bindkey -M vicmd "\e[6~" history-beginning-search-forward
...
EOF

みたいな感じで、普通にコマンドラインの手順のバッチと、catを使ったファイル生成から成り立っているのだが、ステップ中で躓いた場合、Vimでd:2してそのステップからやり直すようにすれば良い。 dggでない理由は、「失敗時にそのステップを終了する」ため、先頭で

TRAPZERR() { exit 48 }

としているからだ。

付して述べるなら、「理解していなくても使える」というのはInflatonとしては嬉しいことではなくて、「理解する前提で育てる」方向だから、 「知悉しやすい、教材としても優れたものにしておく」という考え方になってもいる。

プロビジョニングツールを使うことでディストリビューション間の差異を吸収しやすくなるという面はあるが、 ディストリビューション変更をするような場合は、パッケージに含まれるファイルの詳細を把握しなければ潜在的に危険であると考えているので、そのような吸収をしてもらう必要はない。

同様にプロビジョニングツールを使うことで構成することそのものを容易にする面もあるが、そもそも構成が普通でないので、これも全く役に立たない。 例えば私は個人としては2017年までサーバーにDeleGateを使っていたが、DeleGateを構成することなど誰も考えていないし、そこまで極端ではなくとも常に普通にはない構成になっている。 こうしたことから、定番の構成を容易にする機能というのは助けにならず、こうした機能を理由にツールを選択することもない。

サーバーに依存したツールを使うことも、「サーバーの変更」という選択を難しくさせるので、望ましいとは思えない。

Sharhiveって何か

Sharchiveの話をしたら、「それなに」という方がいたので、「あぁ、そうか。思いっきり昔話だもんなぁ」というわけでちょっとSharchiveの話をしよう。

概要

Sharchive (Shell Archive)はアーカイブファイルフォーマットである。filename suffixは.sharで、コマンド名もshar

アーカイブが7bit ASCIIで書かれたshスクリプトになることが特長。展開時はシェルスクリプトとして実行することで展開できる。

「危険ではないのか」という意見に関して答えると、非常に危険である。 純粋なシェルスクリプトであるため、Windowsの自己解凍形式なんかよりはるかに危険である。

背景

Sharは1995年頃まで使われていた。 tarがアーカイブファイルとしてはまだ一般的でない頃に使われていたのだが、アーカイブファイルフォーマットとして主流だったことはない。間違いなくやや特殊なアーカイブだった。

Unixプラットフォーム上ではshがあることは期待できたので、そうした互換性問題を回避するという面はあった。 だが、Sharが使われていた頃であってもtarがないということはそれほどなかった。

Sharが使われた最大の理由はネットニューズである。

ネットニューズを知らない人は多いだろうが、だいたいやりとりの感覚としてはメーリングリストに近い。 そして、当時はMIMEが制定される前で添付ファイルというものはなかった。つまり、データはメール内に書くしかなかった。 なおかつ、まだ8bit目がチェックディジットに使われている時であり、7bit ASCIIでしかメールが書けなかった。

もちろん、この頃でもtarでアーカイブを作り、uuencodeする、という選択肢はあった(Base64という選択肢はまだなかった)。 だが、これだとネットニューズで見ただけでは、それがどのようなソフトウェアなのかということを推定することができない。 Sharchiveであれば、特にスクリプトファイルやソースコードの場合、ネットニューズ上で確認するだけで内容を把握することができる。 メールと違い、uuencodeされたソースを展開するには取り込んでから保存してソースを取り出すという手間があるし、今と違ってX window system前提というわけでもなかったのでコピペが簡単にできたわけでもない。

こうしたことから使われていたのだが、バイナリサイズが大きくなってくると目視は困難だし、効率も悪く、なにより目視確認できないSharchiveは危険極まりない。 これによって、MIME制定以降Sharchiveは使われなくなっていき、やがて全く使われなくなった。

現在

Manjaroの場合sharutilsというパッケージがextraに存在する。

FreeBSD/DragonflyBSDのtarはlibarchiveを使っており、Sharに対応している。--formatオプションやaオプションで作成可能。

もちろん、展開はshでできる。そのため、展開そのものは今も苦労なくできる。

もはや使っている人はいないレベルだと思うのだが、Mimir YokohamaやInflatonでは使う場合がある。 その理由は、コマンドラインツールの利便性や説明の統一を狙って、Git for Windowsをインストールし、Git Bashを使う、という手順で説明することがあるからだ。

サーバー側はLinuxだし、zipでは返しづらい部分もある。こうした理由から手順が統一できるsharを使う…ということをしていたのだが、 現在は「Git for Windowsにtarが入っている」ことに気づいたのでこれも廃止した。

ネットスラングLOL表現の変遷

どうもインターネット上を眺めていると、ネットスラングLOL表現について自分の育った環境下が全体であるように理解している人が多く見受けられ、そもそも知らない人が増えているようなので、ここで一旦まとめておきたいと思う。

なお、これらは私の手元にある集積的データベースにおいて確認されている情報であり、少なくともそれなりの信頼性はあるはずだが、必ずしも事実ではない可能性があることをご了承いただきたい。

LOL表現の歴史

(笑)

「(笑)」という表現は非常に古く、少なくとも1991年には既に見られる。 fjなどで見た記憶はないが、パソコン通信、ワープロ通信において黎明期から広く使われていたものと考えられる。

JIS X0208の括弧を使う「(笑)」は1998年頃から衰退。 1997年頃から入れ替わるように右括弧を省略する「(笑」が登場してくる。 1996年頃から「(爆)」「(涙)」「(泣)」といった表現が増えており、やがて右括弧省略形に発展するような形。

「(笑」のような右括弧省略形も割と息が長く、この表現の展は噂の「(暗黒微笑」なんかにつながっていく。

1997年頃にはサブカルチャー作品でこのようなネットスラングを使うキャラクターが登場する。

lol表現以外に様々な表現が可能なのがこの表現形式のメリットだが、絵文字の普及と共に廃れてゆく。

藁, ワラ

藁やワラといった表現が登場するには2000年頃から。 ローカルにはそれ以前から散見されるが、主には2chで流行している。

ちなみに、「(わら」を含めて「(笑)」を「わら」と読むようになるのは、1998年以降、ネットゲームにおいてであり、それ以前は(変換の都合もあるが)「わらう」と読むのが主流である。1999年頃になると対談記事などにおいても普通に「(笑)」が登場するようになるが、「わらう」とふりがなが振られている場合が多い。 (個人的には「わらい」と読んでいたが、やや少数派)

「わら」と読んでいたのは1999年以降の新参が多い印象だが、またたく間にこの読みが普及し、「わら」という音で表現されるようになる。

このことから藁、ワラといった表現が誕生する

wara, w

2chで使われるようになるより以前から、ネットゲームでは「わら」という読みが一般化しており、チャットでの変換の手間を省いて「わら」と表現されるケースが非常に多くみられる。

これは、チャットでのタイピングが行いづらいネットゲームの特性によるものだろう。一般的なチャットでは「わら」という読み及び表現は普及していない。

2000年以降に「w」が登場する。これはさらなる簡略化を求めて「w」だけを打ったものであり、「ローマ字入力変換なし」に由来するため、当時のMS-IMEに依存し全角である。

半角wが使われるようになるのは2003年以降。この頃にはネットゲームに限らず使われるようになっている。 特に若年層に浸透し、「(笑)」という表現は「ダサい」とされるようになる。

このときの若年層というのは基本的にケータイ(今で言うガラケー)ユーザーであるため、「w」を打つことは利便性がないどころか打ちにくいはずなのだが、広く使われていた。

この流行により急速に「藁」「ワラ」といった表現と廃れていき、また表記する場合でも括弧を伴わなくなっていく。

もっとも、若年層に浸透するよりも早く普及した2chにおいては「w」という表現は従来「(プゲラ」と表現されていたものに対応していたため、かなり強く嘲笑のニュアンスがあった。

ところが、2008年頃からこの事情は逆転していく。 つまり、「w」が徐々に(というより急速に)嘲笑としてのニュアンスなしに使われるようになり、逆に「(笑)」と閉じ括弧まで含めた形式が嘲笑のニュアンスで使われるようになる。

これはかなり複雑な経緯で、そもそも「(笑)と書くのはダサい」という風潮を前提として、(笑)という表現を馬鹿にして用いた、ということに由来し、これによって「(笑)と書くことによって馬鹿にしているニュアンスが伝わる」という状況が発生し、故に「(笑)という表現自体が嘲笑のニュアンスに見える」という変遷である。

これを踏まえてか、あるいは他の類推からか、括弧を伴わない「笑」という表現も増加する。 これが嘲笑のニュアンスなしに感情を伝える良い判断である、ということのようだ。

「w」を否定的に感じない人、というのは実のところ割と限られた文化圏であり、 一方でwや(笑)に対して嘲笑のニュアンスを取る人も意外と少ない。

とはいえ、「w」を重ねることで強く嘲笑のニュアンスを表現するということは今に言ったても行われているし、そのことを含めて「w」が「品のない発言である」と伝わること(こちらは嘲笑のニュアンスに関係なく、そのようにとる人が多い)も理解すべきであろう。 インターネットは自分の可視世界が全てではなく、公言することには責任がある。

草生える → 草

「wを重ねる」というのは、2ちゃんねるでも特に民度が低いとされた一部だけの文化だが、これに影響を受けたのがニコニコ動画である。

そして、ニコニコ動画において「wを重ねた状態」つまり「wwwwwww」が「草に見える」ことから、これを「草を生やす」と言われた。 あるいは、タイミングとしては判定しがたいが、2ちゃんねる内でそのような一部板以外で「w」を重ねることに対して「草を生やすな」という窘めが行われていることから、こちらが先行かもしれない。

いずれにしてもニコニコ動画が流行していた頃はユーザーは若年層が多く、「かなりの部分2ちゃんねるのユーザーとかぶっていた」ということであるらしい。

この場合の「草を生やす」は笑うことではなく、「wを重ねること」を述べているのだが、w自体が浄化された結果、「草生える」という表現が嘲笑のニュアンス関係なく(嘲笑の場合もあって)「笑える」「おもしろい」という言葉として使われるようになった。

これはそもそも感情にフィットする語感の良い言葉がなかったところへ、簡潔かつsound goodな言葉がついた形になる。

さらに発展し、「草生える=笑える」を「草」と表現するようになる。 草自体が「笑える」ことを示すようになると、「草を生やす」という表現は衰退。「草原」といった表現は減少しつつも、そのペースは「草を生やす」と比べると遅い。

ちなみに、この表現がoriginなわけではなく、これ以前の「ワロス」の置き換えであり、後には「こんなん笑うわ」(これも「こんなんわろてしまうわ」からの派生)も登場している。

「HTML」とwebの話

最近、「webエンジニアは閉じた世界しか見ていないのだろうか?」と感じるようなことがいくつもあった。

例えば

  • Ruby on RilasとRubyを混同する
  • JavaScriptとJQueryを混同する
  • 言語処理系と言語を混同する
  • 著名なフレームワークを使うのが当然であり、それ以外は存在しないものと考える
  • 全く異なる分野や利用法で使われている技術だということを頑なに認めない
  • 自分が勤めている会社の構造や手法や評価尺度が社会的絶対基準であると信じる

などだ。

で、今回は「HTMLとwebを同一視し、HTMLをwebだけのものであると考える傲慢さ」についてである。

HTMLの歴史と経緯

HTMLとwebは根本的には同一である、というのは正しい。

多くの人が知るとおり、webはCERNにおいて論文共有・参照手段として登場し、HTMLもまたこのために登場している。

HTMLはHyper Text Markup Languageなわけだが、「Hyper Text」とはなにかといえば、ハイパーメディアの一部たるテキストである。 じゃあハイパーメディアとはなにかといえば、multimediaに関連性をもたせたものである。

この場合、ハイパーメディアといいつつも現実的に考えられるのは画像くらいのものであった。 だが、潜在的には画像や動画を含めることができることを意識していた。

それらを文書でつなぐ、それがHTMLの役割である。 実際、HTMLのアンカーは「ハイパーリンク」と呼ばれている。

ここでは「マルチメディア」というのがテキスト、文書を含むものであることを忘れてはいけない。 これもまた当然に立派なメディウムである。

HTML2の時点では構造化文書であることが非常に強く意識されていた。 と、同時に、これが視覚的メディアであることもまた強く意識されていた。 この時点では論理性というよりも、視覚的意味合いによって構造化されるという感覚が強く、この過程は同じく論文のためのフォーマットとして誕生したTeXへの意識(あるいはroffへの意識)が感じられるものであった。

そう、ここまで構造化文書というのは、「章立て」といった概念はあるにせよ、文書自体が論理的構造を持っている、というのとは少々異なった。 論理的構造と視覚は一体だったのだ。これが当たり前のことであった。

HTML3によってこれは混迷を極めた。「webをリッチにしたい」という欲求はとどまることを知らず、JavaScriptが誕生し、より装飾的な機能が多く追加された。

一方で、HTML3時代には2つの、異なる意味が生まれていた。

ひとつは、web技術の応用だ。 webをあくまでWWWの世界に留めるのではなく、より広く使いたいという考え方があった。 既にWWWはインターネットの主要コンテンツであり、コンピュータはインターネットのためのものになりつつあった。 競争に勝ち抜くにはweb界の覇者となる必要があり、そのために力を注いだ技術を他のところでも使いたいと考えた、という流れだ。 例えばWindows 98のActive desktopなどがそれである。

もうひとつは、文書フォーマットとしてのHTMLの普及だ。 従来ドキュメントフォーマットというのはあまり良いものがなく、恐らく最善なのはPDFであり、そこにいたるまでのTeXであった。 Windowsは(docドキュメントを含め)いくつものドキュメントフォーマットを持っていたが、それらは標準化されておらず、Microsoftに閉じた存在であった。 roffはman roffであっても「イケてない」と考えられていた。 なにより最大の問題は表示向きでなく、HTMLは圧倒的に表示に適しているということだ。

だから、HTMLはヘルプドキュメントをはじめ、幅広く使われるようになった。 単にドキュメントファイルとして使われるだけではなく、様々なところで組み込まれて使われるようになった。

HTML4は決断のフォーマットであった。 HTMLはドキュメントフォーマットである、という立場を明らかにしたのである。

その上で拡張の余地として、

  • 動的要素を必要とする場合はクライアントサイドスクリプトを
  • 視覚的要素を必要とする場合はstylesheetを

使用するように求めた。 ちなみに、stylesheetとはイコールでCSSのことではなく、それがわからない人はJSSやXSLTについて調べておくとスムーズに理解が進むだろう。

HTML4は至ってstableであった。 諸々の問題はあれど、それらは取り込まれることなく進んでいた。 XHTMLにおける変更は、微々たるものであると言って差し支えあるまい。

だが、WWWの世界ではその間に様々なことがあった。 HTML4以降の歴史を動かしたのはGoogleであったと言って差し支えないだろう。 Ajaxが注目されるに至るまでの流れもGoogleのものであったし、HTML5策定時のGoogleに影響力は果てしなかった。

そして、Googleは明確な「オンライン派」である。 そもそもユーザーが直接にドキュメントを扱うことを良しとしない。だから、「HTMLをオンラインのものにしたい」と考えた。 これに対して反対する声、つまりレガシーなTeXのようなHTMLを尊重すべきだと言う声も強く、初期ではどちらかといえば「ドキュメントフォーマットである」という既定路線を維持する状況にあった。

だが、WWWがさらに成長し、webアプリケーションが基幹を握るに至り、すなわちGoogleが世界を支配するようになると否とは言えなくなってくる。 最初から「オンラインHTML」寄りだったAppleの存在の存在も多少あるが、この過程においての存在感は小さい。結局のところGoogleに対して否を唱えられる存在は既におらず、競争力という点も鑑みてMozillaがこれに同調したことにより、HTML5は「ウェブアプリケーションを提供する基盤」として位置づけられるようになった。実際、CSSには大手ウェブサイトが導入しているトレンドデザインをより簡単に書く方向となり、ウェブレンダリングの挙動はこれらを優先する(これらとことなるレイアウトデザインを許容しない)方向に振れた。

だが、必ずしもそれをよしとしない考え方もあって、HTML5というのは様々な思惑が混ざりあった言葉になった。

HTMLとCSSとJavaScript(ECMA Script)

HTMLとCSSはW3Cが、JavaScriptの仕様であるところのECMA Scriptの仕様はECMAが標準を策定している。

重要なのはこれらが「独立したもの」であるということである。 HTMLがCSSとJavaScriptと共に使わなければならないわけではないし、CSSがHTMLと共に使わなければならないわけではない。 それぞれが独立したものであり、これらは「ハンバーガーとポテトとコーラ」のような関係であるといっていいだろう。

独立した存在であるというのは、それ以外が存在しなくても成り立ち、なおかつそれ以外のものとも組み合わせられる、ということを意味している。

そもそもECMA Scriptに関していえば、JavaScriptの標準というわけでもない。 JavaScriptはECMA ScriptにないDOMに関する機能があり、こちらはW3Cが策定している。 結果として、JavaScriptに明確な言語仕様というものがなく、複数の(ある程度の互換性を持つ)実装が存在するに過ぎない。

ちなみに、「JavaScriptの実装」というと、「ChromeとFirefoxでしょ」と言う人がいるのだが、これは間違っている。 まず、Crhomiumが採用する(そしてNodeやElectronも使う)v8 JavaScriptエンジンがあるが、MozillaはC/C++で書かれたSpiderMonkey(Firefoxで使われているもの)のほかに、JavaでかかれたRihnoを持っている。 Safariが使っているJavaScriptエンジンはKJSソフトウェアがベースでv8とも別物。 Internet Explorerの最終的なエンジンはChakraで、Edgeも独自の実装(EdgeHTML)だった。さらに、OperaはPresto(JavaScriptエンジンのコードネームはCarakan)を採用していた。 Prestoは独自エンジンであり、プロプライエタリなので現存しないが、KJS SoftwareベースのJavaScriptエンジンを使うブラウザは(プロジェクトが生きているかどうかは置いておいて)存在するし、w3m-jsなんてものもあったりする。

webから独立したJavaScriptといえばRhinoを搭載するソフトウェアが実は結構多い。 Javaで書かれているアプリケーションから利用するのが割と簡単なので、SpiderMonkeyが圧倒的にウェブで使われているのに対し、Firefoxでは使われていないRhinoはアプリケーションでプラグイン機能を実現するために使われるようなことが多い。

また、Node.jsもv8ベースで有名な非ウェブのJavaScript利用例と言えるだろう。 ElectronになるとHTMLやCSSも含めてChromiumの機能を利用する形なので、非ウェブと言い切っていいのかどうか疑わしいが、それでも非WWWであるのは間違いない。

CSSに関してはほぼHTMLに依存している。XMLで使うこともできるのだが、この場合「XMLをHTML扱いする」という意図になってしまう。 このような場合はどちらかといえばXSLTが好ましく、XML CSSは基本的にウェブブラウザでXMLを表示するためのテクニックだ。

ただし、HTMLの外観を定義するのはCSSだけというわけではない。 JSS(JavaScript Stylesheet)というのもあるし、これ以外に関しても仕様上制約されているわけではない。 JSSが使われることはごく稀だが、実際に限定的なHTML(あるいはそのサブセット)に対しCSSでもJSSでもないスタイルシートを定義している場合が見られる。近年はレンダリング部分を既存のものに委ねる傾向が強くあまり見られなくなってきてはいるが。

HTMLの用途と位置づけ

ウェブにしか関心のない人は知らないかもしれないが、HTMLは広くドキュメントフォーマットなのである。

基本的なものであるにもかかわらず、ドキュメントフォーマットというのは今に至るまで以外なほど発展していない。 Microsoft Wordの強さというのもあるだろうが、ドキュメントフォーマットが「印刷向け」であるのも大きい。

純粋なドキュメントフォーマットとしては、現在使われるものとしては

  • PDF
  • PostScript
  • DVI
  • Microsoft Word
  • Open Docuemnt
  • RichText
  • roff
  • ePub
  • DocBook
  • HTML

あたり。 それらを生成するフォーマットは多くて

  • Markdown
  • GFM
  • PHP Markdown Extra
  • Pandoc Markdown
  • その他Markdown方言
  • ReSTructured text
  • TeX
  • LaTeX
  • POD
  • RDoc
  • Plain2
  • Asciidoc

などなどかりなたくさんある。

これらは「印刷か表示か」という点で性格の違いがある。 例えばLaTeXはプリプロセッサが処理するための正しい情報になる論理性があるが、出力自体は「太字」など視覚的な定義になっている。 これは、印刷してしまう場合、内部的にどのような情報を持っていたとしても失われてしまうことになるので、視覚的な表現が重要になるからだ。

manroffなどは端末上で表示するためのものだから、端末で表現可能な内容に偏っている。

Windowsヘルプフォーマット(.HLP.CHM)やDocBookなどは対応する環境が少ない。 結果的にオンラインドキュメント1で汎用性・交換性が高い形式というのはHTMLに限られてしまう。

次いでePubということになるだろうが、ePubは書籍を前提としており、オンラインドキュメントに最適化されているとは言い難い。2

この状況で、人に配布する整形済みドキュメントフォーマットとしては「HTMLが望ましく、HTMLしかない」という状況が存在している。 もちろん、ここではHTMLのサブセットはHTMLに内包するものとする。

webの世界というのはドキュメントを基本とするものであり、「みんなアプリケーションなんだからHTMLもアプリケーション化すべき」などというのは乱暴を通り越して愚かである。 HTMLの世界はwebに限らず広がっている、というのは、基礎教養と言えるだろうし、それ以上に自分の了見でのみ物事を定めようとすることを愚かと呼ばずしてなんと呼ぼうかという思いだ。


  1. オンラインドキュメントとは、コンピュータ上で読むドキュメントという意味であり、ウェブという意味ではない。

  2. ちなみに、ePubはそもそもXML/XHTMLベースであり、CSSを使用するものだから独立したフォーマットと呼べるかどうかはあやしい。

「シェル」と「端末(ターミナル)」の違いと詳細

【超ざっくり解説シリーズ】シェル(Shell)とは?シェルについて初心者にもわかりやすく解説するよというnoteを読み、ちょっと内容がひどかったので、Twitterで言及したものの、ちゃんと説明したほうがよかろうと考えて急遽、この記事を書くことにした。

「シェル」「端末」「端末エミュレータ」「端末デバイス」については、Mimir YokohamaのLinux基礎初級「シェルとコマンドライン」の中でやっている。 この内容をやる時期としてはかなり難しい部類に入り、かつ重要であることから、最近は端末デバイスを直接叩くといったことを含めて2時間以上じっくり取り組むことが多い。

内容自体はそれほど難しくはないと思うのだが、理解に至るには

  • 入出力
  • デバイスと接続
  • カーネルとシステムコール
  • プロセス
  • ファイルディスクリプタ
  • デバイススペシャルファイル

に対する理解が前提となるため、ちゃんと認識できていないと難しいかもしれない。

なお、このあたりはOSによって非常に大きな差異があるところなので、ここではLinuxを前提に説明する。 ここに書かれている内容では理解に至るには足りないと感じられる方は、ぜひMimir Yokohamaの授業を受けてみてほしい。 じっくりと丁寧な説明とハンズオンによって理解できるまでしっかりと授業を行っている。

カーネル

カーネルはCPUの特権モードで動作するプログラムである。

実際に定義としてはそれしかなく、カーネルが実際にどのような仕事を担っているかというのも特に決まってはいない。

とはいえ、カーネルにやってほしい重要なこととして「リソース管理」というものがある。 最近のOSはタイムシェアリングシステムなので物理的な装置数以上のプロセスを起動することができるから、プロセスが好き勝手にリソースを使ってしまうと色々奪い合ってしまうのだ。 一番わかりやすいのは、「ハードディスクのアームをどっち方向にどれだけ動かすか」というモーター制御を奪い合ってしまうという状況ではないだろうか。

というわけでリソース管理をするためにカーネルとしてはプロセス管理をしなければならぬ、ということになる。

だが、カーネルというのは基本的にそういうことをする。 つまり、コンピュータを使う上で必要な環境を整える、コンピュータという舞台を作る、というのがカーネルの仕事だ。 ここが改善されるとそれを使う全てが改善されるため開発にも力が入るというものだ。

端末とコマンドライン

カーネルはプロセスを起動する仕組みを提供し、起動したプロセスを管理してくれるのだが、ここで問題になるのは「どうやってプロセスを起動するか」だ。

Linuxの場合、カーネルロード時にinitというプログラムを実行し、initが色々なプログラムを実行するようになっているのだが、 これでは任意のタイミングで必要なプログラムを実行するという方法がない。 また、プロセスやカーネルにユーザーが対話的にやりとりする方法がない。

いや、実際にそう時代もあったのだ。 コンピュータがパンチカードマシンだった時代、プログラムを実行するというのはパンチカードを差し込んで読み込ませることだった。

だが、タイムシェアリングシステム時代になると、ユーザーとコンピュータは「やりとり」をする必要が生まれた。 それも、できるだけ使いやすく。

ここで使われるようになったのが「テレタイプ」である。

テレタイプというのは通信機能(送受信機能)をもったタイプライタである。 言ってみればモールス信号とFAXの中間みたいな感じで、電話回線を通じて(手動交換機を通じて)ほかのテレタイプの紙に印字できる。

テレタイプ自体は1920年代には存在していたもので、1960年代にコンピュータに接続して使われるようになった。 当時の「最もポピュラーのコンピュータとユーザーが意思疎通するための機械」だったのだ。

ユーザーは、タイプライタ同様にテレタイプでタイピングをする、あるいは予め打ち込んで紙テープに出力したものを読み込ませることでコンピュータに対して意思を伝える。 コンピュータからの出力はテレタイプを通じて紙に印字される。

この仲介をするのがシェルなわけだけれども、この時点ではシェルと呼ぶようなものは必ずしも必須だったわけではなく、単純にテレタイプ・インタープリターのようなものであったし、 それ自体が「OS」と呼ばれることが多かった。

Linuxでも端末のことをテレタイプ(tty)と呼ぶが、実はUnixですらテレタイプは過去のものだった。 1970年代にはビデオディスプレイ端末が登場しており(Unixは1973年に登場)、Unixの端末というと紙テープではなく画面を使うもののイメージが強い。

紙テープから画面になることの違いは、「入出力環境が複数行になる」ということである。 例えばUnixのエディタコマンドとしてex(1)とvi(1)がある。 ex(古くはe, そしてee, ed)はラインエディタであり、一行で入出力ができる。つまり、紙テープに適している。 だが、ビデオディスプレイなら複数行を表示し、それを見ながら編集できる。それがvi(VIsual)なのである。

そして、もうひとつ大きな点として「表示上での削除が可能になる」ということがある。

だから、キーボードから打ったものをそのまま解釈してプロセスを起動する、という方法より「よりよい方法」が登場する。 それが「コマンドライン」である。

コマンドラインは、ユーザーはその意図を「行」に記述することができる。 行単位なので、改行したときがその意思の確定である。

このコマンドラインを快適なインターフェイスとして利用できるようにしたのが「シェル」である。

シェル

コマンドラインの基本的な考え方は前述の通りだが、Unix原初のシェルであるshは

  • 行を編集する機能
  • コマンドラインで複数のプロセスを起動する操作
  • ファイルディスクリプタをファイルに対して再オープンする操作
  • 出力ファイルディスクリプタを別のプロセスの入力ファイルディスクリプタへのパイプにする操作

など様々な機能を搭載した「超高機能インターフェイス」であった。 ユーザーは1行の「コマンドライン」の中で実に様々な操作を行うことができる。

今にすればshなんて貧弱極まりないのだが、当時の感覚からすれば「キーボードから打ったものがそのままコンピュータの動作になる」などというのと比べ信じられないほどいろんなことができ、様々に応用できるスグレモノだったのだ。

これがスグレモノである点として、「プログラムを記述する必要性が下がる」というのがある。 インターフェイスが単にキーボードから打った内容に基づきプロセスを起動するだけであるならば、全ての操作は事前にプログラムを用意しておかなければ行えない。 shは実に様々な操作をsh自身によって提供し、なにより応用が効くようになっていたので、圧倒的にプログラムを書くのではなくコマンドラインを打つことで目的を達成できるようになったのだ。

基本的には、bashであれ、zshであれ、それらの「機能が豊富で便利」という点を強化したにすぎず、基本的には変わらない。 シェル自身もプログラムであり、別に特別なものではない。ただ、「インターフェイスが何もなければ対話的にコンピュータを使うことはできないが、シェルはただ対話的に使えるだけでなく、対話的に 便利に 使えるインターフェイスだ」というだけの話である。

カーネルに対して特別にくっついているわけではないし、Linuxシェルはユーザースペースで動作し、別にシステムコールを直に叩くわけではなく汎用性のあるライブラリ(例えばglibc)をロードし、実行する「対話的プログラム」でしかない。

ただ重要な点がある。シェルが登場したとき、コンピュータとやりとりするための機械はテレタイプ、あるいはビデオディスプレイ端末であった、ということだ。

Unixはそれがどちらであっても、あるいはどこのメーカーのテレタイプであっても抽象的に扱えるように「デバイスファイル」という仕組みによって扱うようになっている。 そのため、「端末デバイス」という抽象化したレベルで取り扱うことができ、この端末デバイスは、テレタイプのような一行のものなのか、あるいはビデオディスプレイ端末のような複数行のものなのか、という情報と合わせて取り扱うことができる。

現在は端末デバイスではなく、ビデオデバイスを通じて出力し、キーボードを通じて入力するのが普通だ。 これは一般的には「X Server→ビデオデバイス(カーネルインターフェイス)→ビデオドライバ(カーネル)→ビデオカード(ハードウェア)」の構成であるが、シェルは依然として端末デバイスを必要とする。 普通、シェルは直接にX Server、あるいはビデオデバイスを扱う機能はもたされておらず、あくまでも端末デバイスを使って入出力を行うようになっている。

端末、仮想端末

だが、現在本当に端末に繋がっているコンピュータなんてまずないので、物理的に端末を意味する端末デバイスファイルが用意できない。

そこで、実際には端末はなくても、端末デバイスとして扱える仮想端末デバイスと、コマンドラインの入出力に適した仮想端末ソフトウェアが使用される。

「テキストモード」においては、「仮想コンソール」と呼ばれることが多いプログラムを使用する。 このプログラムは、ビデオデバイスによってテキストビデオモードを設定すると共に、(テキストビデオモードの)ビデオデバイスを通じた画面出力と、キーボード入力の処理機能、 そして仮想端末デバイスの提供(Linuxでは/dev/tty*)を行う。 その上でシェルを起動すれば、シェルは/dev/tty?を端末として扱うことができるわけだ。

ターミナルエミュレータは単なるX client(あるいはWaylandクライアント)である。 つまり、グラフィカルアプリなのだが、これはこれで仮想端末を提供する。Linuxでは/dev/pts/*である。 やはり、この上でシェルを起動すれば、シェルは/dev/pts/?を端末として扱うことができる。

だから、例えば

% ls -l /proc/$$/fd/0
lrwx------ 1 haruka haruka 64  6月  1 00:19 /proc/2835/fd/0 -> /dev/pts/0

ということである。

なお、端末エミュレータはキーボードを処理しない。X serverから受け取ったキー入力を仮想端末デバイスを通じて入力するようになっている。 だから、「シェルの標準入力はデフォルトでキーボードに繋がっている」というのは嘘で、対話的シェルは入出力ともに端末デバイスに繋がっている。 仮想コンソールの場合、シェル→端末デバイス→仮想コンソール→キーボードと間接的につながっているのだが、ターミナルエミュレータの場合は全く繋がっていない。

ちなみに、「端末」といえば、DECのVT-100である。 1978年にリリースされたビデオディスプレイ端末で、まぁとにかく売れに売れて、端末といえばVT-100というレベルだった。

だから、VT-100の仕様が一般的で、VT-100と互換仕様の端末も出たし、仮想端末もだいたいVT-100と互換になっていたりする(そして、その設定がある)。

そして、もうひとつ。

xtermは、それを端末として扱うための色々なものを、自前でもっていたりする。

【Manjaro/Arch Linux注意】Yaourtは廃止になりました

すごくニュースだと思うんだけれど、全然話題になっていないけれど。

AURヘルパーである YaourtはAURからなくなりました

もう随分長いこと「非推奨」とされてきたのだけれど、ついになくなった、というかたち。

AURヘルパーの中ではYaourtが最も親しまれてきたし、最も有名だった。 「Yaourtを使う」というのが当たり前になってもいた。

けれど、近年はセキュリティ上の問題があり、メンテナンスされていないことからobsolateになっていた。 で、今ついにAURからなくなった、ということ。

これに伴って、CommunityパッケージになっていたManjaroでもYaourtは廃止に。

今後はyayなり、Trizenなりを使っていくことになる。

そのうち「Yaourtを野良ビルドして使う」みたいな記事が出てきそうだけれども、 危険なのでやめましょう

Archwikiでは2019-05-20現在、日本語版はそのままであるものの、英語版はYaourtに関する記述自体が削除されている。

Axon7故障 → AQUOS R2 Compact購入

弱いAxon7

Axon7が壊れた。 画面が砂嵐になる、という症状だ。

どうもこれ、Axon7にとってはよくあることのようで、報告例が非常に覆い。 実際、私も以前この症状で一度交換している。

画面の接触の問題だそうで、強く押し付けたり踏んだりすると直ったりするし、 これで一時的に直してデータ移行をしたいのだが、画面がうつらなくなる可能性があるのではとても使えないので、嫌なタイミングではあるが機種変することにした。

Axon7に関しては、画面の問題以外にも、重量や発熱など基本的な部分に加え、やや不安定な挙動、WiFiをロストしがち、音楽再生中にオーディオボリュームを変えられてしまう、といった問題もあり、正直使っていてそんなにいいとは思えなかった。 ただし、Dolby Atomos, SD820, 3.5mmジャックありという構成自体は、音楽聴くにもゲームするにもよく、カメラ性能もそこそこ良いため、まぁまぁ活躍したのは確かだ。

移行先の選択

まず、前提としてサブ機である。

メイン機は6.4インチのOPPO R17 Proがある。ブラウジングや入力系、そして圧倒的なカメラの性能を踏まえてのカメラ機能に関してはこちらに任せることができる。 SD710なので、性能もまぁまぁ高い。また、画面が綺麗なので、写真を見たり動画を見たりするのも(スマートフォンではほとんどしないが)メイン機扱いで良い。

サブ機の主な役割はアカウントの使い分けという面を除外すれば、音楽を聴くこととゲームである。 そのため、

  • SDカードスロットと3.5mmジャックがある
  • オーディオエンハンスがある
  • SD820よりゲーミング性能が高い
  • 画面操作がしやすく、反応が良い
  • できれば小さく、軽い (ただし、ゲーミング性能を損なうなら非優先)

を条件とした。

SD820よりも性能を要求しているのは、主にはやっているゲームのためだが、 それ以外にもGPU的に重いアプリがいくつかあり、GPU性能が高いほうが快適性が高いためである。

最有力はAQUOS R2 Compactとした。

これは、登場時から、「SD845で、軽く、小さい。SDカードに対応していて3.5mmのジャックもある」ということから、まさにR17 Proの補完に最適であると考えていたからだ。 AQUOSスマートフォンは経験上、非常に上部で壊れない、という点も私を後押ししていた。 また、以前ASUS Zenfone 4 Selfie ProとZTE Axon7の性能・特性・得手不得手が似過ぎていて棲み分けが出来ない、という問題も踏まえている。

その上で店にいったのだが、日本語がやや拙いおねえさん(私にOPPOを推した人でもある。 でも購入したのは違う店だった)推奨のNova3が対抗の候補となった。 値段的にもR2 Compactより4割近く安いのは魅力的ではあった。

SDカードスロットがあり、オーディオエンハンスがあり、なおかつKirin 970を搭載しており、要件は満たすのだが、6.4インチでやはりR17 Proとの棲み分けが難しい。 また、Kirin970の性能、体感的にはSD710を搭載するR17 Proと比べても高くはないように感じられた。R17 Proは結構さくさく動くのだが、Nove3はフリップアニメーションなどがちょっと遅い。

もっと安い端末でめぼしい選択肢もなかったことから、当初の狙い通りR2 Compactを選択した。 大きな点としては、「Nova3もそんなに安いわけではないので、微妙に気の進まない端末を買うよりは愛用できる端末を買うほうが安い」という判断であった。

SH-M09 AQUOS R2 Compact 概要

SD845を搭載しながら、5.2インチディスプレイを搭載した145gのコンパクトスマートフォンである。

「5.2インチならそんなに小さくない」と思うかもしれないが、131*64*9.3(mm)で、132*66*9.6(mm)で4.9インチだった先代AQUOS R Compactよりも小さい。サイズ感としては、5インチスマートフォンよりも明らかに小さく、4インチ台だった昔のスマートフォンに近いサイズ感。重量も140gから135gへと軽量化された。

ただし、9.3mmという厚みは、6.4インチのR17 Proが7.9mm、特に薄かったZenfone 4 Selfie Proが6.85mmということを考えると、こちらもクラシカルで分厚い。アルミフレームだし、昔のiPhoneのようだ。

先代がSD660, 3GB RAM, 32GB ROMといったミドルクラスの性能を与えられていたのに対し、SD845, 4GB RAM, 64GB ROMというフルサイズのR2同様の性能が与えられている。「コンパクトスマートフォンはアンダークラス」という位置づけを破り、「R2のコンパクト版」に切り替えてきたわけだ。 画面が小さいので、自ずからSD845機の中でもベンチマークスコアは特に良い。

元々はソフトバンクキャリアで出ていた端末で、「らしく」、防水・防塵に対応。IPX5/8/IP6Xと本格的である。インカメラは8Mpxにすぎないが、アウトカメラは22.4Mpxと妥協なく、ディスプレイは2280x1080pxで120HzのハイスピードIGZO。 アウトカメラが22mm相当の広角レンズで、しかも光学式手ブレ補正つきあるという点も大きい。インカメラも画素数こそ少ないが、広角レンズで使いやすい。控えめな美顔機能もある。

「小さい」という点を除けば基本的にはハイエンド機の構成である。

さらに、最近のハイエンド機が失ってしまった、SDカードスロットと3.5mm4極のステレオヘッドセットジャックを持っている。

スマートフォンに全方位要求するが、手が小さいため大きい端末が選べないと歯噛みをしていた女性には最高の端末ではないだろうか。

ちなみに、特に女性向けというような売り方はしておらず、カラーラインナップも白と黒とくすんだ緑となんとも微妙。

使用感

速い

スマートフォンでここまで速いと本当に驚く。

私の印象ではスマートフォンというのは操作ごとのレスポンスが遅く、待ってばかりである。 指を離して次に指を置くまでの時間に操作が完了していないのは、もはや欠陥といっていいレベルだと思うのだ。

webの表示も遅く、快適性が極度に乏しい。 私がスマートフォンをあまり使わない理由がここにある。スマートフォンを10分使うなら、コンピュータを起動したほうが時間の節約になるし快適だ。

だが、R2 Compactは操作からして速い。 単純にアニメーション時間が詰められているのかもしれないが、アニメーションが速く、webの表示も速い。 さらにいえば、通信自体速く、Wi-Fiでのやりとりも速い。アップデートも速いし、アプリインストールも速い。 もう、「こんなに違うのか」と驚いてしまう。

120Hz描画のパワーもあり、さらに速さが強調される。最高である。

小さい。 軽いかどうかというと…

うちはたくさん端末があるのだが、パット見にR2 Comapctは古い端末に見える。 厚みがあってアルミフレームというクラシカルな外観も要因のひとつだが、いかにスマートフォンは大きくなっていくものだという認識が当たり前のものであったかというのを感じてしまう。

小さいだけに135gといいながらもった感じはむしろ重い。 ただし、持ち運ぶときは明らかに軽い。重さを感じるのは手で持っているときだけだ。

シャツの胸ポケットに完全におさまるサイズなのも良いところだ。

充電速度は弱点か

R17 Proは10分ちょっとで10%から90%まで充電してしまう超高速タイプであり、出かける直前に「あ、バッテリー」となっても着替えている間に間に合う。 Axon7もそこそこ速く、20%ほどでもごはんを食べている間に充電すれば60%は越える。

だが、R2 CompactはmicroUSB時代の急速充電と同等である。 1時間で20%くらいしか充電されないので、夜の間に充電しておくような戦略が必要になる。 USB Type-Cになってからはバッテリーマネジメントの戦略が不要になっている端末が多いだけに、この点は明確に欠点だと思う。

機能面は切り捨てられているレベル

ソフトウェア面で使いやすいかと聞かれると、「非常に使いにくい」とこたえざるをえない。

そもそもAndroid9が使いやすくない、という問題もあるけれど、それ以上に問題が山盛りである。

まず、「もつと画面点灯」が使いにくい。画面が拭けない。 これは「AQUOS便利機能→自動画面点灯→持つと画面点灯」でオフである。

Android9の問題である邪魔なGoogleアシスタントは、「Google→検索、アシスタントと音声→アシスタント→アシスタント→アシスタントデバイス→スマートフォン」でオフにできる。 深さに抵抗を感じる。

Android9の問題、WebViewでのフォーム入力をGoogleに送られてしまうことについては、「設定→Google→Smartlock for Passwords」でオフにすることで解消できる。

ゲーム中でも画面をスリープにされてしまうという問題は抑制する方法がない。画面スリープまでの時間を伸ばしておくのが現実的。

ナビゲーションバーは隠すように変更できるが、ナビゲーションバーを隠している場合、引き出す操作の反応はいまいち。 指紋センサーをマルチホームボタンとして使うことができるのだが、これはうまく操作するのは非常に難しい。ただし、指紋センサーのところにエッジがあるタイプの保護ガラスを使えば指紋センサーによるナビゲーションが現実的になる。

指紋センサーの反応はすこぶる良い。ただ、良すぎるため画面ウェイクアップを抑制しにくい。 指紋は、Android9の仕様に従いGoogleに保存される仕組みであり、嬉しくない。

導入されているアプリは

  • おサイフケータイ
  • からだメイト
  • OfficeSuite
  • SHSHOW
  • アルバム
  • コンテンツマネージャ
  • エモパー

と非常に少ない。 音楽プレイヤーすらない。今はサードパーティ音楽プレイヤーに対しては扱い厳しいのに。

ホームアプリも素のものに近いが、独自のものではある。

かといってGoogleアプリを入れまくっているわけでもない。

エモパーは大量の権限を要求する上に、現在地情報をオンにしておくことを要求する。 アルバムはカレンダーへのアクセスを要求する。

基本的な端末のハードウェアなどは悪くないので、設定などを練っていく手間をかけることになる。 OPPOはだいたいほしい設定になっているだけに、設定把握からはじまり面倒だ。

設定項目の追加などもなく、基本的には素のAndroidという感じ。 最近のAndroidが不十分であると感じている私にとってはいまひとつ。

良い点として、SH-SHOWはかつては「着メロ配信サイト」としての価値を担っていたが、現在においても色々と壁紙だったり、テーマファイルだったり、着メロだったり、あるいはS-Shoinの辞書だったりを配布していて、結構便利だったりする。 昔はパケット代を気にしてあまり使えなかったものだが。

ゲームはとても良い

私は「ゴシックは魔法乙女」というシューティングゲームをやっているのだが、反応が良いのでとてもやりやすい。 今のところ慣れないので被弾が増えてしまっているが、慣れてしまえば問題ないと思う。

ハイスピードIGZOのおかげで120Hz表示ができるのが良い。 何気に将棋ウォーズのエフェクトのなめらかさが際立っていたりする。 ちなみに、速さは将棋ウォーズでも生かされ、速く描画されるのでスピード戦である3切れはだいぶ有利。ただし、盤面が小さく、誤タップを警戒すると指すのはそんなに速くならないが。

「ゲームなら画面は大きいほうがよかろう」と思っていたのだけど、むしろこれこそいいのかもしれない。 重めの「カスタムキャスト」なんかももちろん問題ない。もたつきなく操作できる。

音楽は…悪くはない。

Dolby Atomosのインテリジェントモードはいまひとつであり、結局グライコがついているだけ、ということになってしまう。 疑似3D機能がなく、Axon7のものよりシンプル。

ただし、3.5mmジャックが上側にあり、グライコがあるというので十分でもある。

プレイヤーはPulserを使っているが、再生中はロック画面がアルバムカバーに置き換えられるのもまた良い。 ただし、そのせいでロック画面で文字がみづらく、ロック解除が困難になることもある。

優秀な日本語入力

日本語入力はS-Shoin。

画面が小さい、で最も最初に問題になるのは「スクリーンキーボードが打ちにくい」なのだが、S-Shoinは小さい画面でも打ちやすく、良好な予測変換を行う。私はATOKも買ってあるのだけれど、今のところS-Shoinを使いつつけている。

シャープ製端末はiWnnで、日本語入力に強いという印象はなかったのだが、2015年夏からS-Shoinが投入されたらしい。 これは大変良い。

なお、「Shoin」というのは恐らくシャープのかつてのワープロ「書院」から来ているのだろう。 なんとも懐かしい。 私はシャープ製のケータイ(フィーチャーフォン)を使ったことがないので知らなかったが、「ケータイShoin」なるものもあったそうな。

ちなみに、なぜかベトナム語と中国語のGboardが入っている。

留守電機能搭載

スマートフォンの非常に大きく、明快な機能的後退が端末の留守電機能がなくなったことだ。 キャリア製端末を使うのであれば、キャリアの留守番電話に加えて端末で使えることも多く、逆にMVNOユーザーとしてはどっちもなくて非常に困ることが多い。

私はほとんどの場合電話が出られない状況にあるので、留守番電話がない、というのは電話としての価値を大部分損なっているといっていい。

恐らく、Google的にはSMSがあるから必要ないという考えなのだろうし、実際欧米ではSMSが結構日常的に使われているのだが、 日本ではほとんど使われていないし、実際SMSが来ることはほぼないし、SMSを送ると「使い方がわからない」「受信者負担がある」といった理由で怒られることすらある。

AQUOS R2 Compactには「簡易留守録」という留守番電話機能が搭載されている。 ちなみに、AQUOS PHONE全般に搭載されており、AQUOSケータイにもある機能であるようだ。実際私はAQUOSケータイを持っているが、留守電機能は大変重宝している。 自動音声営業で埋め尽くされることも多いが。

この機能単独で選択理由になるレベルである。

持ちやすいけど、汚れやすい

基本的に端末はもちやすい。 が、どうも静電気強めのようで、ほこりがよくつく。しかも、背面ガラスなので指紋もよくつく。

結局、カバーとスクリーンガラスは必要だろう。 ただ、形状自体が持ちやすい上に小さいので、リング等を使わなくても、PVCカバーだけで十分機能を果たしてくれる。

Y!Mobileについて

ビックカメラ店頭でR2 CompactがY!Mobile非対応となっていたので気にしていたのだが、実際は問題なく使うことができた。

ただし、MMSに関するエラーが出てしまうので、Y!Mobileのページに従ってAPNを修正する必要がある。

評価は

★5である。

「使いにくい」を強調しておきながら…と感じるかもしれないが、結局のところ必要な機能が全てそろっていて、その機能が支障なくしっかり機能することは何者にも代えがたい。 目的に沿う、という理由で買っているので、それがしっかり果たされればそれだけで結構な満足ができる。

そして、SD710でも、Kirin970でも感じることのできなかった「速さ」が、明らかなストレス軽減につながっている。 機能面は設定やアプリ導入でかなりの部分が改善できるので、あまり深刻な問題ではない。OPPOのように明確なアドバンテージを生むことはできないが、それでもZTE端末や、HAUWEI端末でできる程度であれば何の問題もないと言える。

ハードウェア的な欠点、つまり「汚れやすい」「指紋センサーナビゲーションが使いにくい」が保護ケースや保護ガラスによって解決するため、ハードウェア的な弱点も残らない。

求める機能がしっかり機能し、その上でストレスがない、というのはもうその時点で満点をつけていい。

メイン機として考えれば、私はもうColorOSを知ってしまっているので、「メイン機はOPPOだろう…」という状態だからあまり話にならないが、もしOPPOがないとしたらメイン機でもぜんぜんおかしくない。 この場合、「ブラウジング用」あるいは「Twitter用」もしくは「YouTube用」にサブ機みたいな話になるのだろうか。 全方位強いのだが、「物理的に小さい」ことだけはいかんともしがたい。 ただし、それでも5.2インチ端末であり、「画面が小さい!!」というほどでもない。小さい端末いっぱいに画面というのはかなり強力なようだ。

解決できない問題を挙げるとしたら、充電速度になるだろう。 必要とされる直前に充電する戦略がとれず、出かける時間とバッテリー残量を気にしなければならないのはちょっとしんどい。

その点だけは明確に足をひっぱるのだが、Axon7においては決して快適とは言えない使い心地(特に日本語入力周りと重量、持ちにくさ)だったのに対し、小さく軽く、もちやすく、快適な性能と入力を備えるR2 Compactは、これ単独で持ち歩いくことが既にある。 Axon7時代は「Axonだけを持つ」ということはなかった (この端末は「プライベート電話、仕事ネットワーク」の構成である。メイン端末は逆で「仕事回線、プライベートアプリ」になっている) ので、これは体感的な使い心地を直接に表わしていると言えるだろう。

カスタムキャストでキャストデータを移行する

アプリとしての出来が悪いままのカスタムキャスト

ドワンゴのVTuber戦略は相当不調らしい。 まぁ、「当然だな」という越えがおおかったりもするのだが、登場当初は非常によく遊ばれ、期待も大きかったカスタムキャストがいまひとつ普及していないのも、その現れなのかもしれない。

カスタムキャストは元はアダルトゲームのカスタムメイドがベースになっている。 あれは、エディット機能自体は優秀なものの、DMM版含め出来がよくないという評判がもっぱらなので、必然なのかもしれない。 ありとあらゆる面でいまひとつであり、そのひとつとして「引き継ぎ機能がない」というのが挙げられていた。

やがて引き継ぎ機能が実装されたのだが、著しい「コレジャナイ感」が漂っている。

ほとんどの人は引き継ぎたいのはキャストデータだと思うのだが、キャストデータは対象外、というか引き継げるデータはほとんどない。 キャストデータを作るのは結構時間もかかるし、再現するのは困難なので、キャストデータが引き継げないとそもそも使い物にならないと思うのだが。

データをコピーすればOK

説明にある通り、キャストデータは端末に保存されている。 保存場所はAndroid/data/jp.customcast.cc2/以下である。つまり、このフォルダ以下をコピーすれば良い。 幸いにも現在データチェックは甘く、キャストデータをピンポイントに上書きしなくても、必要なデータを再ダウンロードする形で通してくれる。

ただ、私が試した限りだとgvfs MTPの制限なのか、このフォルダ以下にコピーすること自体ができなかった。 ただし、ファイルの作成や上書きはできるため、

のようなシェルスクリプト(これはサブフォルダ用)で処理できた。 これ以上深いディレクトリの中身は放置して良いし、cache以下は気にしなくて良い。

Windowsユーザーはどうすればいいか、という話は私が取り扱うべき話ではないから、 このフォルダをコピーすればいいよ、という情報を元にがんばっていただく方向で。

OPPOスマートフォンの「AR測定」がすごい

OPPOスマートフォン(R17 Pro)の先日のアップデートで新たに「AR測量」というアプリが追加された。

これは、カメラを使って距離や角度などを測ることができるアプリだ。

以前一部スマートフォンにレーザールーラーが搭載されていたが、これに代わるもの、というかはるかに強力なものになる。 せっかくのデュアルカメラだし、測量に活用できないかな、と思っていたので、まさに実現した感じである。

使い方としてては対象にカメラでピントを合わせるようにしてポイントすると、照準先のターゲットにアンカーを打ち込む。 これを複数打ち込むことで測定するわけだ。

ここがすごい

最初のアンカーに関してはレーザー測定なのか、離れていると打ち込むことができない。 ところが、ふたつめのアンカーからは結構離れていても打ち込める。

レーザールーラーは便利ではあるのだが、射程が2mほどしかないため、メジャーを当てにくい部屋や家具のサイズを測るのに使えない、という残念なポイントがあった。 ところが、このAR測定はそんなの関係なし、部屋のサイズだって測れちゃう。(ポイントを打ち込むときはレーザーの届く範囲に限られるが、打たなくても計測自体はできる)

また、距離計測でレーザールーラーの場合あくまでスマートフォンからの距離を測るのだが、AR測定の場合三角測量になっていて、カメラを計測対象のポイントに向けるだけでいい。距離の場合、第二ポイントに打ち込む前にポイントとの距離を出してくれる。 「端から端」をはかるとき、スマートフォンを端においてしまうと操作できないので、レーザールーラーは微妙に実用的ではなかったが、これなら非常に使いやすい。

計測できるのは「距離」「長さ」「角度」「面積」。 面積や、他でもカメラを持って移動するような場合は精度にやや不安があるが、だいたい分かれば良い場合は大変重宝する。

ポイントしたあとはその計測マークが画面上に残留する。ここが「AR」なのだろう。 カメラを移動させると、その測定したポイントを結ぶ線が空中に浮かんでいるように見える。 ちなみに、多分測量自体AR技術。

頭いいなぁ。数学の素養の問題なのだろうけど、ちょっとどうやったらこんな測定ができるのかわからない。 OPPOスマートフォンを選ぶ理由がまたひとつ増えてしまった。