不安定なホスト(非固定IPアドレス, 非常時稼働)をサーバーにする

需要があるらしいので、この話。

不安定なホスト(非固定IPアドレス―浮動IPアドレス, ステートフルIPアドレス, あるいは間違っているけれど可変IPアドレス― または 非常時稼働システム)をサーバーにする、というテーマで、 方法はたくさんあるのだが、私の結論は「商業レベルでやることではない」である。

待ち受ける

DDNS

最も普通の方法だが、実際にはかなり制約が多い。

SFPレコードは効かないし、DNSレコードは反映をコントロールできない1ので逆引きが効かなかったりでサーバーとしては結構痛いことになる。

リバースフォワーディング

これはかなり簡単な方法で、例えば次のようにする。

# ssh -g -R 80:localhost:80 serverhost

これによってインターネットから安定して接続できるホストに代理ホストとして公開してもらう。

不安定なホストの非稼働時は代理ホストが応答する。

フロントエンドプロキシ

リバースフォワーディングと同様に代理ホストに公開してもらうのだが、不安定なホストに通信を転送させるのではなく、中継させるという方法。

まずなんらかの方法で代理ホストと不安定なホストを接続する。 例えばVPNで接続する。

# pppd updetach noauth silent nodeflate pty "ssh root@remote-gw /usr/sbin/pppd nodetach notty noauth" ipparam vpn 10.0.8.1:10.0.8.2

あるいはSSHによる転送を行う。

$ ssh -R 8080:localhost:80

そして、代理ホスト上でリバースプロキシを動作させる。例えばSquidやNginxをプロキシとして、ローカルネットワークホストとして、あるいはローカルホストの別ポートとして転送する。

VPNで接続している場合、代理ホストからは不安定なホストは不安定なグローバルIPアドレスではなくローカルなIPアドレス10.0.8.1として認識される。

不安定なホストの非稼働時は代理ホストが応答する。

逆接続モデル

利用可能なサーバーが限定されてしまうが、サーバーからクライアントに接続するモデルがとれるのであれば、不安定なホストであることはあまり問題にならない。 あるいはサーバーリレーするタイプ(送信専用メールサーバーなど)でも機能する。

VPNで接続する

インターネット公開しているのでないのならば、代理ホストを経由するなどしてVPNで接続し、ローカルなアドレスを代わりに使うという方法が効く。

非IP

「IPアドレスが固定でない」ことはIPアドレスを用いる場合にのみ問題として発生する。 だったらIP以外で通信すれば良い。

ただし、この場合はほとんどローカルなIPアドレスで運用する方法も適用できる(VPNで接続するなど)ことになるし、 リンクローカルな通信であることがほとんどだから、これを転送するハードルを考えるとあまり易しくはない。

例えばセキュリティの都合上でIP接続を許可していないAoEサーバー、なんていうのはアリだ。

Zeroconf

リンクローカルでIPアドレスが固定でないことを考慮しなければならないケースはあまり見当たらないが、 リンクローカルなのであればZeroconfが使える。

IPアドレス制限されたホストに接続する

レンジで許可する

ステートフルに割り振られるIPアドレスのレンジが十分に制限されているのであれば範囲で許可すれば良い。

ゲートウェイ経由

固定IPアドレスを持つホストを経由して接続する。

SSHならば割と簡単にできる。

$ ssh -L 10000:destination.example.com:10000 proxyhost

VPNで代理ホストを経由しても良い。

別の方法で接続する

例えばSSHやVPNなど特定のポートだけIPアドレス制限の対象外とした上で、これらのセキュアトンネルを通じて接続する。

MySQLサーバー等、認証が強力でないサービスのためにIPアドレス制限がなされているのであれば、SSHのように認証が強力な方法についてはIPアドレス制限から除外し、これを経由することを許す、というわけである。

許可されているホストに依頼する

ゲートウェイ接続はできないまでも融通の効くホストで接続が許可されているホストがあるのであれば、これをプロキシとして接続する。

このような場合普通はアプリケーションプロキシとして使うか、SOCKSプロキシとして使うものだ。 このプロキシに対する接続に認証を求めるべきで、異なる方法で安全性を担保させるわけである。

ちなみに、以前紹介したSSHフォワーディングの場合

  1. ローカルなポートフォワーディングにより代理ホストから不安定なホストに通信を中継するようにする。 (これ自体は公開されていない)
  2. プロキシコマンドとして外部ホストから代理ホストに対して接続を行う
  3. これによって確立された経路を使って代理ホストのlocalhost(lo)に対してSSHを通す (これがダイナミックポートフォワーディングによって不安定なホストに転送される)

という方法で、計3本のトンネルが通されることになる。


  1. 「TTLに従う」と信じているなら、ちょっとハッピーすぎる。

兵庫県警、無害なジョークプログラムを紹介した人々を逮捕

どんなこと

兵庫県警は13歳の少女をはじめダイアログループの書かれたウェブサイトへのリンクを掲載した数名を逮捕した。

本質的には一行のコードである。

ちなみに次のようにも書ける。

これがそもそもどの程度の話か…というと、 正直、「ほんのいたずら」というか、もはや、「いたずら」ですらなく、「悪ふざけ」のレベルである。

実害は全くなく、昔はすごくよくあった。 で、結局そのためにアラートが出ている状態でも閉じられるようになった。

だから、対策として

  • アラートが出ているからといって閉じられなくなるわけではない
  • タブを閉じることも、ウィンドウを閉じることもできる
  • 「このサイトで再度ダイアログをを表示しない」というオプションもダイアログに併記されるので、これを使えばダイアログを表示させずページを表示しつづけることもできる

とどうとでもなることで、なにか困ることがあるわけでもない。 GoogleのMariko Kosakaさんによれば

危ないかと聞かれれば、アラートの無限ループはデバイスを壊すわけではなく、個人情報を盗むわけでも無いです。ブラウザはアラートを消す・ページから去る方法を提供していますし、安全を担保するためにsandboxという概念(子供が砂場を荒らしても砂場内だけで、外には害が及ばない)を採用しています。

警察の環境は20年前の化石?

このようにダイアログループを抑制できるようになったのはNetscape Navigator 4からで、20年前のシロモノである。

それを「閉じられなくなった」「コンピュータの利用に支障をきたした」というのなら、兵庫県警サイバー課なるところは、20年以上前の機材を使っていて、かつそれ以降の知識はまるでアップデートもされておらず、そんな人たちが取り締まっている、ということになる。

これがどれだけヤバイことかは、1999年がどんな時代だったかを知ればわかる。

  • 最新のOSはWindows 98SE
  • 携帯電話にはまだカメラがついていない
  • 携帯電話はまだパカパカ(シェルクラム型)が主流になるより前
  • 携帯電話でのメールは有料で、同じキャリアとしかやりとりできないのが普通。 それも、「カタカナで20文字まで」だったりする
  • インターネットは電話線を使って「中継局に電話をかける」アナログモデム式。速度は56kbps (今の1/1000)
  • コンピュータで動画、は技術的には存在するものの実用性に乏しいもの
  • DVDは登場したばかり。 LDは一般的(家庭にはあまりない)
  • 音楽はCDまたはMD。主流はカセットテープ
  • Skypeも登場前で「インターネット無料通話」というものはない。 そもそもインターネット接続は電話代とISP利用料金の従量制でかなり高く、インターネットで通話できるからといって「無料」という感覚は全くない

この時代の頭で「犯罪」だの「悪質」だの言っちゃうわけだ。

日本が全世界の笑いものに

これはよく使われる煽りとかではなくて、本当に 既に 笑いものになっている。

例えばJavaScriptの産みの親であるBrandan Eichさんのツイート でも、「Netscape 4でJavaScriptのループを止められるようにしたぜ」ということを言っている。

Brandan Eichさんは笑っているというよりは怒っている感じだ。 JavaScript生みの親として意見する用意があると言ったとか。

ZDNetでは「Coinhiveを埋め込んだことで人を監獄送りにしたはじめての国」と日本を紹介している。

GoogleのMariko Kosakaさんは大したことではなく、ひどい話である旨発言している。 ちなみに、同氏は

腑に落ちないので何度も言いますけど、for(;;){window.alert('lol')} が「不正指令電磁的記録に関する罪」ですよ(しかも今回は作成が問われたんじゃなくて共用が問われてる)。 誰が不正指令電磁的記録か判断してるの?書類送検受けた検察はどんな取調べするの?

「不正指令電磁的記録供用未遂」だって。sanspo.com/geino/news/201… そうだろうと思ってたけどやっぱり刑法168条の2だ「人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録」っていう拡大解釈が大変懸念されるアレ。

といった発言をしている。 繰り返すが、これは Googleの中の人である

このあたりのBrandan Eichさんと、Mariko Kosakaさんの発言はIT Mediaに記事としてまとめられている

もちろん、世界中からというだけでなく、世間的にも笑いものになっている。

これに対して電凸した人もいるようだが、

日本から子供を消すのか?

「補導」というとやわらかく聞こえるかもしれないが、13歳だから補導なだけで、実質的には逮捕である。

今回の場合、実害がなく、些細な悪ふざけにすぎない。 しかも、本人がやったのではなく、やっている場所を指し示しただけだ。

これと同等のことをした人が逮捕されるのだとしたら、ピンポンダッシュをした子も、落書きをした子も、「ひじって10回言ってみて」と言った子も、みんな逮捕である。 だいたい、ノリとしても被害としてもこれらと同等であり、内容的にも近似している。

この程度の悪ふざけを逮捕すべき事柄だとするのであれば、多分日本から子供はいなくなるだろう。 こうして学習や社会から学ぶ機会を奪われた子供は社会的に生きる能力を持たないし、多くの場合この程度で投獄するのだから、子供は皆投獄されるという話になる。

前提として、法律というのは 恣意的に運用してはならない という前提がある。 もし同じ罪を犯せば その全てが必ず裁かれねばならない のだ。

もし、これと同等の事が重大なる罪であるというのであれば、そのようなことをした人は全て逮捕されるということになる。 子供のいたずらは言うに及ばず、日本でプログラマになれるのは好奇心によって色々試したことのある者ではなく(そのような者の行動は必ず逮捕される)、職業訓練によって言われたものを言われたままに書くことだけを覚えた者だけだということになる。

子供がいなくなることを含めて、確実に日本という国の終わりである。

一方、もし「同じこと、あるいは同等のことであっても全て逮捕されるわけではない」とする(恣意的な運用を行う)ならば、「都合の悪い相手、気に入らない相手、虐げたい相手を投獄する」という、今で言うと北朝鮮よりもさらに悪い国家統治を行っているということになる。 というより、私は過去をみても世界中でこれよりひどい運用を行った法治国家というものを知らない。 そして、実際はこちらであると感じている。法治国家として、 決してやってはならないこと なのにだ。

Coinhive事件から連なる邪悪な行動

そもそもこの話は直接関係ないように思われてしまうが、

  1. 「不正指令電磁的記録に関する罪」の創設
  2. Coinhiveでの逮捕

と深く絡んだ事件である。

「不正指令電磁的記録に関する罪」は「ウィルス作成罪」などと呼ばれたが、「プログラムにバグがあるだけで捕まる」「プログラムを習得しようとするとどうしたって捕まる」「プログラムについて言及するだけで捕まる」などと非難が相次いだ。

これは大喜利的悪ふざけではなく、事実全てのプログラムに関わる人と、プログラムに言及する話題が犯罪要件を構成してしまうものだった。 それに対して「慎重に運用するので言われているような懸念は的外れだ」などと返してきたのだが、そもそも「普通に社会生活を営んでいる人が必然的に犯罪要件を構成するような法律に問題がある」という指摘は無視された。

その上でのCoinhive事件であった。 この事件については以前にChienomiで触れたが、これがまさに「悪質かどうか、内容がなんであるかに関係なく当該法律を拡大解釈して逮捕した」という実例だった。

これは世間的にも受け止め方は微妙だった。 というのは、悪質な広告同様に、Coinhive自体は肯定的には考えにくいものであったこと、また他者のリソースを裏でこっそり使って小遣い稼ぎをしようという思考に抵抗があったことから、「逮捕すべきかどうか」ということと混同してしまう事態を生じたからだ。

結果的に、そのような誘導があって「不正指令電磁的記録に関する罪の拡大解釈と恣意的運用」がまかり通ってしまった。 そして、さらなる拡大解釈と恣意的運用がなされた結果、今回の事件となったわけだ。

また、実際にその恣意性でいえば、今回のケースでいえば「不正なサイトへのリンクを貼れば罪になる」という話なのだが、 私はウィルスへのリンクを貼っているメールや、詐欺サイトへのフィッシングリンクを含むメールなどはとても積極的に通報する方針でやっているのだが、 対応されたことは一度もない

「捕まえやすく、抵抗しづらい相手を逮捕する」ということをしているわけで、純粋な弱いものいじめ、そして陵辱である。

ちなみに、兵庫県警のウェブサイトはGoogleアナリティクスが埋め込まれており、これは訪問者にとっては不可視だから、まさに「利用者にとって意図しない動作をするスクリプト」なのだが、これが話題になってからこっそりと削除するという対応をした。

漉さんの発言は大変良いと思う。

sudoの注意書きこそ、今、兵庫県警をはじめとした捜査機関と、広く報道すらメディアの人に読んで理解してもらいたい。

・他者のプライバシーを尊重する

・行動する前に考える

・大いなる権限には大いなる責任が伴う

検証不可能性重視 = 「悪事を働く恣意がある」

昔から、というかそもそも法律を定めた時点から、日本の司法は密室で行われ、その検証を許さないという傾向にある。 実際、公判によって公開されているように見えても、実際は予め打ち合わせされた通りに進行しており、その打ち合わせは非公開。ただのセレモニーである。

そして、その検証や公開は罪になる。

だが、言うまでもなく、「なにをしたかということを人目に晒せば罪になる」というのは、要は「人目については困る」「暴かれては困る」わけで、最初からやましいことをする気でいるということである。

今回も逮捕の対象になったものが何であるかということを確認することが「危険であり、また犯罪になる可能性がある」と注意喚起したことで「全く問題のないものを拡大解釈によって逮捕した」という事実を隠そうとしたわけだし、実際そのように「検証を求めて提示することで逮捕される」という状況を作り出したことで、「実際に自分で踏んで確認すべきだ」と主著ぅした高木浩光さん1でさえもそのアドレスの掲載は控えた。

もちろん、その内容に害はなく、ZDNetをはじめ海外のメディアは遠慮なくそのコードやアドレスを掲載していることから、実際に警察が強権を振り回すことで人々が萎縮し、検証の目が働かない事態になっていることが明らかである。

そもそも、外部の目や意見に左右されることなく他者を害することができる力というのは明らかにバランス悪く過剰なものである。 大きな力であればこそNoと言われれば行使できないものでなければならず、日本という国はこれまでも潜在的には人を虐げうる国として成り立ってきたが、それが顕在化する傾向が非常に強まっていると言えるだろう。


  1. セキュリティ専門家。産業技術総合研究所情報セキュリティ研究センター主任研究員。

「若い人はスマホを使いこなしている」は本当か

この言説、結構みかけるのだけど、実際のところ私は「間違った言説である」と思っている。

この言説についてちゃんと考察してみよう。

根拠は

おそらくは「使っていること」特に「抵抗なく使っていること」にあるだろう。

実際、おおよそそうだと思う。私は全くそんなことはないので共感はできないが、感想上の実感としても加齢とともに新しいことに対する拒絶感が強くなり1、能力的に習得可能か否か、あるいは理解可能か否かとは関係なく「受け入れないから」習得できない (というか、積極的に「習得しない」という選択をする) と言える。

こんなものは興味関心の強さが使えるようになる度合いに直結しているので、差が生まれるとすれば積極性しかない、とも言える。 別に脳の構造がそもそも違うわけでもなければ、概念の違いが特別習得困難性を生じるようなものでもない。

なぜ積極性が生まれないのか

電車の中で観察する限り、特に年齢によるハンディキャップがあるように見えないし、「若くないからスマホが使えない」というようにも見えない。 ただ、以前はややその傾向があったのは確かだ。スマホを特に好むのは20代前半以下であり、それより上の世代は保守的でスマホ自体に対して否定的な傾向があった。

この構図はごく単純に、「学生はスマホを使っている子がいれば羨んだし、ある程度普及すればスマホでないことがコミュニケーションディスアドバンテージになったから、人間関係を円滑にするためにそもそもスマホが必要だった」のである。 大人になればコミュニケーションの必要性や頻度、そして切実度は下がる傾向が強いから、既に大人であった人にとっては、例えケータイがなければ困るという実態があったとしても、「スマホがなくては困る」ということはそれほどなかったのだろう。

しかし、大人であっても遅ればせながらスマホが浸透し、「みんなが使っている」という事実が出来上がっていけば「スマホであるべき」という状態に流れていくし、スマホの便利な使い方が確立されるに従って相対的には「スマホでないことが不便」という状態になっていく。 だから、大人でもスマホを使うようになる、というわけだ。2

現在スマホの必要性を感じていない人は、よほどこだわりがあるか、知識があるのでなければ、周囲にスマートフォンを積極的に使う人が少ない、あるいはリモートコミュニケーション密度が低い、もしくはその両方なのではないだろうか。

より広く考えても、結局のところ「何らかの理由で積極性を持つものはよく使うようになり、積極性を持たないものは仮に技能を保持したとしてもあまり使わない」という結論になる。 実際、私はスマートフォンに関して一般ユーザーよりは知悉していると自負するが、ほとんど使わない。電車の中でも特に必要がなければいじらないし、家の中でいじることは基本的にない。

そして、世代によって、というよりも「中学生である」「高校生である」「新米社会人である」といった属性によって文化的差異から身近か否かという階層化が生じ、その結果世代によって得手不得手が発生する。 現実として、ちょっと昔は「若い子はパソコンを使いこなしている」と言われたが、現在はコンピュータを得意とする若い子というのはかなり少ない。

本当に使いこなしているのか

コンピュータであってもそうなのだけど、「使う頻度」と「使う幅」には必ずしも相関性はない。 例えば、LINEとツムツムのやり方だけ覚えて、ずーーーーっとLINEとツムツムだけしている人が、突然スマートフォンを高度に活用するように求められていともたやすくできるわけではない。そして、そのような高度な使い方を習得するとして、明確なアドバンテージがあるわけでもない。

「抵抗がなく、使う機会も多いから触っている時間が長い」ということは、単にスマートフォンの利用量と依存度の問題であって、技量を意味していない。

じゃあ、例えば

  • コミュニケーションメディアの特性や問題点や仕様を正確に把握して使い分けられるか
  • アプリのセキュリティ上の問題を把握しているか
  • 同種の複数のアプリの中から状況に対して最適なものを選択できるか
  • スマートフォンの仕組みを理解し、説明することができるか
  • スマートフォンを活用して達成したことがない目標を提示されたときにスムーズにその達成に導くことができるか

というと、そんなことはなくて、むしろスマートフォンを使うことが「自慢できるような先進的なこと」だったときに早期に飛びついた人はかなり高い積極性を持って使っていたから結構詳しくてスキルも高かったりするのだけど、現在は使い方が確立されていることもあって、既知の知識と行動の範疇が「常識の枠組み」となってしまい、スキルは上がらなくなってしまっている。

どちらかといえば「当たり前にあること」は(特段の積極性がなければ)向上面ではプラスに働かないのだ。

近年のスマートフォンなどに代表されるUIは「直感的」だと言うが、実際のところこれまた好奇心に依存するものであり、今や普通になったハンバーガーメニューでさえもスマートフォンライクなUIが先進的だと思って使った人はその探究心から理解しようとして理解できたということでの「直感的」だったし、故に戸惑うことなく利用できるが、既存の知識を利用して使っている今の若い子は今するところも、操作方法もわからないという傾向が強い。3

結局、「若い、という理由で使いこなせているように見えるならば、それは自身の好奇心の衰退と挑戦心の喪失と保守化を示している」と考えて良いのではないだろうか。


  1. neophobiaになる理由はいろいろ言われているが、単純に変化を様々な理由で嫌うことと、現状で目的を達成できているという驕りあたりが特に理由ではないか、とは思う。ただ、そもそも「推測可能な理由がたくさんある」時点で「全然不思議ではない」ということでもある。

  2. 実は私もスマホに対してはかなり保守的で、「持ってはいるけど全く使わない」という状態だった。スマホになったのは、携帯電話ハードウェア的にフィーチャーフォンが利便性を低下させたこと、サービス的にフィーチャーフォンでは利用困難になっていったことが大きい。つまり、「相対的にスマホが便利だから」ではなく、「機能的にフィーチャーフォンの優位性も損なわれから」という理由で、筋金入りである。スマホをちゃんと使うようになったのは2015年からで、これは「willcomがY!Mobileになって、フィーチャーフォンラインナップがなくなった」という理由である。

  3. これはちゃんとデータをとった上で述べている。

毒性オープンデータ症候群

オープンデータとは一体

オープンデータは基本的には国政から出た言葉のようだ。 どうりであまり聞き慣れないと思った。

私の周囲のFacebookerたちがやたら繰り返すので何事かと思ったのだけど、まぁ、予想通りというか。

基本的にというのはどういうことかというと、そもそもの話をすれば情報に対する非占有というハッカー的な文化を別のところがかっさらって形式化したものを日本政府が流用した、というような感じで、もはや理念はどこへやらである。

だが、この話はそう簡単ではない。

「オープンデータ」の概念と価値

そもそもデータというのはなんらかの形で発生するか、蒐集されるものである。 この場合、特に蒐集されたデータが重要になる。

エンジニアは必要があればデータを用意する。 典型的な例でいえば都道府県の47選択肢があるが、あれは手打ちすることが圧倒的に多い。 手打ちがそこまで難しいとは言わないが、ミスが発生する可能性とかかる時間を考えるとしないでいいのであれば避けたい。だから近年はコピペで済ませる人も増えている(そして同じ罠にはまる人も増えている)。

この場合は47要素しかデータがないが、もっと複雑な場合もある。 場合によっては専門的なデータも、一般に有用な場合も多い。

行政はそのようなデータを非常に多く持っている。管理する必要性があって持っているのだが、そのデータを蒐集することで賃金が発生している人がいると考えて良い。 であれば、そのようなデータを民間において再度用意することは一種の車輪の再発明になる。そもそも、行政でなければ整えられないデータというのもある。

だから、「使えるか」「使いやすいか」ということとは関係なく、これらのデータを外部秘とせず共有するということは単純に価値がある。

この観点からいえばウェブというのは原則オープンデータである。 近年はウェブにおいてその利用を制限するのが当たり前になっているが、これはウェブの原理原則に反している。

オープンデータという「形式」の話はどちらかといえばウェブを中心にして考えられているらしい。 それもどうかとは思うが。

情報が入手可能かどうかという点は断絶に等しい差があるので、単純に(データの形式によらず)内部で持っているデータを公開し、その利用に制限をかけないだけでもオープンデータとしての価値があると考えて良い。 というより、ハッカーであるならばそこまでくれば如何様にでも、という話ではあるのだ。

データ形式とエンジニアの怠慢

ところが、なぜか「そのまま使えるデータでなければけしからん」という人が多いらしい。

ちょっとそれは実力と創意工夫の欠如に対する吐き気がするほどの怠慢だと思う。

たとえばこのモーメントのお話。

要は、

  1. 2016年祝日名称
  2. 2016年祝日月日
  3. 2017年祝日名称
  4. 2017年祝日月日
  5. 2018年祝日名称
  6. 2018年祝日月日

という6カラムデータになっているものに対して

祝日名称,月日

という2カラムデータにしろ、ということなのだが、 間違っていると断言できる。 いう その2カラムデータだと、祝日が廃止、あるいは追加になった場合、あるいは名称も月日も異なった場合の対応関係を確定することが不可能になる。 それは彼の用途においてはそのように用意されたデータが使いやすいのかもしれないが、それは対応関係という情報の欠損を生んでいる。 求めているケースではそれでも良いのかもしれないが、全体で見ればその欠損したデータを必要とするケースはあるわけで、配布データを欠損させることを求めるのはおかしい。

さらにいえば、確かにこのデータは恐らくExcelで読むことを前提としたゴミデータが入っている。 だが、データ解析においてノイズが乗るのは 前提の想定であり 、この場合単純に「第二カラムが所定の形式でない行を捨てる」程度の処理でクリーンアップできる。「収集したデータにノイズがなくクリーンアップの必要はない」という考えは根本的に間違っており、例え結果的にクリーンアップが必要なかったとしても、それを期待してはならない。

この程度のことができないのはエンジニアではないし、ましてやプロなどとは到底呼べない。 それでいながらこれに対して罵詈雑言を吐いた者は猛省すべきことだと思う。 だってこの程度であればデータの確認から整形まで30秒もあれば済ませられるし、整形はRubyワンライナーでいける。

$ nkf -Lu -w holiday.csv | ruby -rcsv -e 'CSV.new(ARGF, col_sep: ",", row_sep: "\n"').each {|i| i[1] =~ %r:\d+/\d+/\d+: ? print i : next }

「ダサい」のと「何を提供するか」という問題は別

そもそもオープンデータの意義としては、「内部的に使用しているデータを外部にも利用できるようにする」ことであり、これは「内部データがダサければ、ダサいものが白日のもとにさらさられる」という話ではある。 Mimir YokohamaにもInflatonにも、その気になれば外部に公開できないことはないデータというのもなくはないが、基本的にはRuby Marshal形式になっていたりする。Rubyを使う人からすれば「coolだ」と思ってもらえるだろうが、Rubyistでない人たちからすれば非難轟々だろう。 だが、私が作っているシステムはRubyで動いているわけで、Ruby Marshal形式であることは至って合理的だ。

そして、Excelを使っている人(組織)のデータであればExcelらしいデータになるのはやむを得ないと言える。

ここにあるのは、「データが入手可能で、利用可能である」という事実である。 「そこにあるものをいかに使うか」というのは技量と才覚によるものであり、どうしたって差はつく。 それを考えるべきものであり、データ側が自分の事情に合わせるべきであるというのはあまりに自己中心的思考だ。

私だって、公開されたExcelらしさ満点のCSVは「だっさいなぁ」と思う。吐き気がするくらいだ。

例えばInflaton Plutoでは日本郵便が提供している郵便番号CSVを使っているが、これは住所が3パートになっている(分けられていること自体は良いことだ)のだが、「3パートの分け方が一定でない」上に、「一番うしろのパートには “(以下にないもの)” だの “一円” だのと不規則に書いてある」という地獄のデータになっている。

これは祝日データベースと違い情報の欠損があり、さすがにそのようなケースでは私としても悪態をつきたくなる。 それでも、データとして存在するのとしないのでは大違い、できる範囲でカバーするのもハッカーでありエンジニアだ。

データを公開する、という行為に対して「使いやすいようにデータを加工して出せ」と言うのは、「公開をポリシーや情報管理上の問題」という範囲を越えて「データ形式やデータ内容にもさらなる労力を避け」と要求しているのであり、「そんなコストを払うくらいなら公開しない」という判断がなされたとしてもなんの不思議もない。をする。 実際、Mimir YokohamaにしてもInflatonにしても、直接営業的に関係ないもので外部にリソースを利用可能にするためにドキュメントを書くだけでも大変(数時間かかっているようなものも少なくない)なのに、さらにデータを整形しろ、要求するデータを出せなどと言われたら間違いなく「公開しない」という選択をする。

私にとっても、「ダサいデータはやめろ、有用なデータにせよ」とは思うが、それは提供するデータに対する話ではなくて、「Excelでデータを作るなんてうんざりだ」という話だ。 データ形式としては普通にxslxでデータが出てくることもあることを思えば遥かにマシでもある。

一方、それに対して自分の都合でflamingする人はもっとずっと吐き気のする行為であるということに気づくべきだと思う。

そして、最後にエンジニアではなく、オープンデータという言葉に酔いしれている人たちにも含めて告げよう。 「オープンデータは手持ちのデータを公開し、利用可能にするという以上の意味はない。ほしいデータがあるとか、そのまま使えるなどという幻想を抱くのは無邪気な愚者である」と。

はやわかり レスポンシブルCSS

まえがき

リクエストがあったので、レスポンシブルウェブサイトを構築するCSSの基本的な考え方を簡単にまとめよう。

これは、CSSやHTML自体を書けない人を対象にしたものでは ない

ケース分けの仕方

CSSのメディアクエリを使用する。 メディアクエリの詳細についてはMDNに記事がある

ほとんどの場合メディア特性にはwidthまたはheightを使用する。 広く使われてはいないが、aspect-ratio, orientationは基本的なメディア特性であり、非常に有用である。 この両者を組み合わせることで(ゲーム画面のように)スクリーンサイズに合致するレイアウトが可能になる。

典型的なケースでは、レイアウトボックスが1000px幅だとして、ビューポートに1000pxがなければ画面いっぱいにfallbackする。

ただし、このようなケースでは次のように書くべきだ。 そして、実際にこのように書くべきケースは非常に多く、メディアクエリを必要とするケースは表示切り替えくらいのものである。

この場合、#MainBoxは幅1000pxをまず確保しようとする。 しかし、min-widthによって制約されているため、1000pxの幅が包括ブロックの100%を越える場合は包括ブロックの100%に留められる。 これによってビューポート幅を突き破ることがないようにできる。

widthによって判定するのは「コンテナの中央寄せ」という、2003年以来の文法に従っているためだ。 だから、しっかりとデザインするのであればまた異なった設定になるだろう。

HTML構造

基本的なレイアウトでは全体を収めるためのボックスを用意する。

この中にレイアウトしていくのだが、基本的には「左であり、上である」「右であり、下である」という順序で書く。 これを入れ替えるのはCSSでは少し難しい。 ただ、良いCSSを書くには「可能な限りJavaScriptに頼らない」という気持ちは必須である。

「本文コンテナとサイドバー」という構成であれば、サイドバーの内容を上にしたいのであれば左サイドバーになるし、サイドバーの内容を下にしたいのであれば右サイドバーになる。

横並びレイアウトで最も基本的なのは「コンテナをテーブルに、コンテンツをセルに」である。 この場合、例え縮小しても横並びは維持されるし、min-widthなどではみ出す場合、そのままoverflowする。

コンテナ側のサイズが決まっていて、サイドバーのサイズを指定しないことでサイドバーをある程度縮小させることを許すことができる。 これは、最低限必要な幅を確保した上で、それよりも幅があるのであればもう少しスペースをとって表示することができる。

次のCSSでは、1000pxを下回るのであればtableによる表示を諦めるが、ボックス自体は最大1200pxまで伸張する。 1200pxの場合、その割合としてはサイドバーが200pxから300pxの間で、残りがメインになる。

十分なスペースがないときに右のボックスを下に送るのであれば、メディアクエリは必要ない。 inline-blockとして配置することで、overflow時はボックスを並べないようにすることができる。

この場合、サイズ指定は並んだときに確保すべきボックスと、単独になったときに伸張すべきボックスの大きさを意識する必要がある。 また、内包されているボックスの位置と大きさはいずれも#MainBoxにbindされていることを忘れてはいけない。

表示ボックスそのものの変更

ボックスのレイアウトではなく、内容そのものをレスポンシブルに変更したい場合はdisplayを上手に使うといい。 例えば次の場合、#TOCは十分な幅がないとき省略される。

メニューは十分な幅があれば横に配列しようとするが、ないのであればそのまま縦に配列する。

同一の内容に対して異なる表示を提供したい場合は、予め複数書いておくようにして、メディアクエリでdisplay: block;display: noneを入れ替えるのが良い。 この場合、同内容はジェネレータによって生成されるべきである。PureBuilder Simplyの場合、Pandocテンプレートを使うことにより内容の反復を避けることができる。 より一般的にはテンプレートそのものをeRubyなどで生成し、値を置き換えるのが良いだろう。

順序の変更も、「複数書いておいて、表示を切り替える」のが最も無難である。

がんばるのであれば、position: absoluteあるいはposition: fixedを使うことで「見かけ上の順序」をごまかすことができる。 これらはビューポートをそのまま使うブロックに対して指定することが多いためあまり意識しないだろうが、座標起点は包括ブロックであり、また包括ブロックとしても機能する。 以下の例では十分な幅があればサイドバーは左に表示されるが、十分な幅がないとき、サイドバーは下に表示される。

表示コンテンツの変更

レスポンシブルに異なるバナーをコンテンツ中に表示したいような場合は、JavaScriptを利用するほうが良い。 ただし、メディアクエリと背景画像を使うことでCSSで処理できないこともない。

各ページ共通のものであればテンプレートに組み込んで表示ボックスの切り替えが良い。

表示コンテンツの表示の仕方でいえば、max-width, min-width, そしてmarginの値をコントロールするようにするといいだろう。

おまけ。ビューポートを全部使う

文字主体のコンテンツの場合、文字サイズをビューポートに基づくようにすれば問答無用でビューポートいっぱい使うデザインが可能。

5vwは一応、1行に20文字入る計算になる。 この場合、横幅が小さい場合は文字数が、縦幅が小さい場合は行数がある程度確保されるようにするという基準になっている。 その上でなるべく大きい文字にする。画面いっぱい使って大きく文字を表示するのでお年寄りにもやさしい。

標準的に1920pxに対して16pxの文字とすると120文字入るので0.85vhとなるのだが、これをすると非常に小さくなってしまう。

これをやると拡大縮小がかなり制限されてしまうことから、「大きく文字を表示する」前提で考えたほうが良い。 2vhくらいあればちょっと大きめに表示されるが、拡大できないので2.5vhくらいをスタートに考えたほうが良いかもしれない。 特にウィンドウをタイルしたときなどで縦長になるとすごく小さい、などということもありえるのだ。

縦書きウェブ

「悠のおはなしのおはなし」というサイトを始めた。

これは、私が作家として物語について、あるいは物語をつくることについて述べている新しいサイトである。

主たる話題が美少女ゲーム(=アダルトゲーム=エロゲー)であるため、苦手な人も多かろうし決して閲覧を推奨するものではないのだが(PVを欲しているわけでもないし)、このデザインに関してはかなりがんばったので、その話をChienomiでしたいと思う。

縦書き

縦書きプロパティ

CSS3に縦書き関係のプロパティがあることは知っていたのだが、実際試すと随分印象が違った。

縦書き、あるいは段組というのは昔からあった。

段組のほうが古く、段組用のタグはHTML4で廃止されてしまった。 「見た目に関わるタグである」ということが理由だったが、その時点でCSSで代替する方法がなく、そもそも段組というのがHTMLにふさわしくないという判断が働いたようであった。 実際、誰も使っていなかったし。

また、単純に縦書きにすると非常にスクロールが長くなること、そして基点が左上であるため一旦全部右にもっていかなければならならいことからあまり快適性もなかった。

しかし、CSS3の縦書き+段組であれば、「画面サイズにちょうどよいように段組してくれる」という使いやすさだった。 画面に3段収まるのであれば3段、収まらなければ2段といった感じだ。 これは段の高さだけで、段数自体は無限になる。

もちろん、段組などしなければ縦書きは横にスクロールする形になる。 これは単純に縦書きか横書きかの違いになるため、考え方としては横書きとまるで変わらない。 しかし、PCの場合マウススクロールの方向がYだけ、タッチパッドでもX方向スクロールは無効であることが多いので、X方向にスクロールするUIというのは大変嫌われる。

そのため、「縦書きの無限段組」というのは非常に良い挙動だと思う。

ただ、「ePubみたいにフリックでめくりたい」という要望が出たので、後述するページめくりを入れた。

不安定な挙動

理屈上では理想的なのだが、現実としてはやはり「縦書き段組」なんてものをけんしょぅする人が少ないからか、なかなかbuggyである。

なんといっても、ボックスのサイズ計算、位置計算が全ておかしくなる。そして、段組の計算もおかしい。

さらに、リサイズ時の段数が読めない。同じサイズにリサイズされても条件によって結果が変わる。

結局、その抑制のため、幅を取るエレメントを横に並べず、HTML全体を幅90%に制限するという方法をとった。

なお、FirefoxよりはChromiumのほうが安定して描画してくれる。

レスポンシブルと4kスケーラブル

4kの大きいディスプレイを買って感じるのが、「大きな画面を想定していないサイトが多い、ということだ。」 幅が極端にあると、コンテンツは真ん中にちょこんとあるだけ、という状況になりやすい。

トヨタのウェブサイトは現在は真ん中コンテンツ型で、TGRに関しては写真だけ幅いっぱい、という仕様になっている。

幅が小さいモバイル系デバイスの設定はしても、幅が大きいデバイスに対する対応というのはちゃんとしていない、という感じだ。

そこでこれに対する対応として、私は珍しい指定を入れた。

フォントサイズが画面幅によって決まる、ということである。 このため、大きい画面であればピクセル数によらず文字は大きくなる。 段組の文字数を決める上でも扱いやすい。

この考え方、今の「振れ幅の大きすぎるディスプレイサイズ」問題に対応できる気がする。

幅は原則画面いっぱいにしており、幅広ディスプレイにも対応する。 しかし、あまりにも行数が多くなるととても読みづらいため、34行までに制限している。 そのため、さすがに上下タイルとかされると真ん中に置かれてしまうのだが、大画面の最大化ではそうはならない。

ちなみに、今回行数をどうしようかと思って文庫本を色々数えてみたのだが、16から18行が多く、一部19行というものがあった。 さらに合わせたかったのだが、さすがに幅が少なく、見開き分ということで34行としている。もちろん、これはフォントによって結果が変わるが。

UI

ボックスレイアウトが縦書きすると狂うこと、本好きの感覚としては余計な表示は欲しくないことから、トグルボタンを2つ置く、という方法で対応することにした。 ちなみに、いつも通り、CSSのみの対応である。

操作できるものが他になければ操作してくれるものなので、割とイケると思っている。 微妙に表示としては邪魔なのだが、それはご愛敬。HTMLを90%にしたおかげで右側が少しあきやすく、この問題は少し軽減されている。

ハンバーガーメニューはともかく、純粋なトグルというのはあまり見ない設計だが、simplifyという観点から言えば悪くないと思う。

ハンバーガーメニューですらないUIに気づくかどうかについては… トップページにでも書いておいてなんとかしよう。

ページめくり

前述の通りePubのようにページをめくりたいという要望に応じて、swipeとflick両方に対応する簡単なスクリプトを書いてみた。 jQuery Mobileどころか、jQuery自体使っていない、PureJSによるものである。

考え方は単純で、タッチ開始時に座標を保持し、タッチ終了時の座標と比較する。 Y軸は普通にスクロールだから、問題にするのはX軸だけ。 差が閾値以上にあればスワイプ、またはフリックしたものとみなす。

今回、閾値は「画面の1/3以上」とした。意外としっかりとやらないとめくれない。 感触としていまいちなので、今後もっと小さい操作でもめくれるように調整するだろう。

話をすごく単純化しているが、意外とこれで問題なく動作する。

1段の高さははっきりしない上に取得もできないので、単純に画面半分をスクロールすることにした。 おまけのようなものなので実用性は状況によってはあまりないが、ないよりはよかろうということでアクセシビリティツールである。

デザイン

やや黄色がかった背景とグレーの文字は目に優しく、「本っぽい感触」を求めてみた。 本であればもっと黒いのだが、印刷物よりも画面のほうがはるかにコントラスト比が高いことから、よりグレーにした。

タイトルロゴは珍しく実用的にfloatが使われている。 最近はfloatは思い込みで横に並べるのに使われがちなので、多分珍しい。 ロゴの配色は「白枠、色付き背景」というライトノベルの背表紙のスタイルに合わせてみた。

左上に入るページタイトルは、小説の上部に章タイトルが入るスタイルを意識している。

「本なんて特に有益ではない」「本で勉強する必要はない」「本がありがたく高尚なわけではない」という発言を繰り返しているので誤解されがちなのだけど、私はそもそも本好きで、めちゃくちゃ読むほうだ。 最近は「本が入り切らなくなったので動画を見るようになり、動画に飽きたのでエロゲーをやるようになった」という感じで、割と物語ジャンキーみたいな感じで何かしら物語に触れていたいタイプだったりする。

本屋にいけば際限なくに時間を消費してしまうからあまりいかないように心がけているし、横浜に図書館がないことは大変嘆いてもいる。

電子書籍も(普通にPDFなどプレーンな形式で配布してくれるならば)好きだし、紙の本も好きだ。 ただ、どちらかというと私の場合、紙の本なら本棚に入れておけば何の気なしに読んだりするが、電子書籍は明確な動機がないと読まないので、それを理由にどちらかといえば紙の本が好きで、家に無限の広さがあり、引っ越しの手間も考えなくてよいのなら書庫を作って本いっぱい買いたいくらいである。

本を読むタイプの人間としては、「本っぽさ」というのは長文を読むときには結構欲しい。 流し読み、というか斜め読みするときは横書きが圧倒的に早いけど、物語への没入なら縦書きがいい。

紙っぽさ。縦書き。本っぽい文字数。本明朝。 これは私のこだわりであり、これをきっかけに「物語を読む」ことが好きな人が増えてくれたらいいなぁ、という気持ちも込められている。

また、このデザインは、webページのデザインとして上がってきたものを見たときに、「ウェブはかくあらん」みたいな感覚をぶち壊したい、というのもあった。 そもそもそのサイトでは「従来にないデザインの方向性を目指したい」というのがあったのだけど、なぜか「デザイナーから上がってくるwebデザイン」ってすごくありきたりというか、みんな同じようなものを出してくる。(ちなみに、違う感じのを出してくる人は実用性の欠片もないとんでもないものを出してくることが多い。)

それが常識としてこびりついているのなら、「ウェブはこんなことしたっていいんだよ」というのを声を大にして言いたかった。 だから、常識やお決まりからは思い切りかけ離れたサイトを作りたかったのもあります。それは、ウェブのクリエイティビティを失ったエンジニアに対しても。

縦書きプロポーショナル

今回、vpalを有効にしており、縦書きでプロポーショナルメトリクスが有効になっている。

徹底して「文庫本っぽく」仕上げているにも関わらず、書籍ではまず見ない縦書きプロポーショナルは、私のちょっとしたチャレンジだ。 これが見やすいかどうか、ぜひ意見を募りたいと思う。

鳩山元首相の「デマ問題」が問題である所以

あらまし

北海道で震度6の地震があった直後、鳩山元首相が「CCSによる人災」と断定的にTwitterで発言、 北海道警が災害後デマとして注意を呼びかける中にこのツイートを含んだことが話題の発端である。

私は 政治的な話をする気はない ので、別の角度から説明する。

これはあくまで 「インターネットと社会」という観点から一般的にどうであるかということと、それに照らしてどうであるかというお話である。

最大の罪は「無責任な発言→証明の要求」

デマを流す人というのは結構いるのだが、そのほとんどは明確な根拠もなく、そして根拠も示さず、検証に労力を割かない。 つまるところ「放言」である。

そして、その無責任な発言を咎められた時の常套句として、根拠や証明を要求するというのがある。

これは極めて下劣な行為である。 なぜならば、自分は責任を負ってもいなければ、その労力を割いたわけでもないのに、他者にその労力を要求するのである。

このようなデマ拡散に対しての義証明というのは社会的に極めて損失になっている。 無責任な放言などいくらでも言い放題だからコストは非常に低く、能力も必要ない。 そして、そのような気まぐれによって、その証明を担える優秀な人たちが比較にならないほどのコストを負わされるのである。

インターネット時代においてはそのようなデマの拡散がより深刻化し、人類の発展を阻害している。 実害のあるデマの抑止・修正に専門家が大きな時間を取られる。

そして、そのような根拠に基づく指摘をされたところで、無視するか、やはり根拠もなにもなくrejectするかというのが常である。

最大の問題は、このような人類に実害のある愚劣な行為を、仮にも元国家元首が行ったことである。 これはちょっと、呆れるでは済まない。

デマの問題

そもそも流言飛語というのは時として国を滅ぼすほどのもので、全く軽い話ではない。

そして、インターネットでは1デマの拡散というのは 最も重い罪である とされている。 もちろん、当初からデマという問題があった、というのがその所以でもあるが、依然として「インターネット」から見ればデマが最も重い。

理由はその拡散性、というかconnectivityにある。 インターネットは間接的に全体でつながるように設計されている。そして、その空間を流れる情報量というのは有限である。 このインターネット上での情報伝達におけるS/N比というのは、そのまま「インターネットそのものの価値」に直結する。 つまり、ノイズが増えすぎるとインターネットは死ぬのだ。もしあなたが「インターネットに接続すると、有益なものはなにも得られず、ただひたすらゴミ情報ばかりが送りつけられる」という状態になったならば、あなたはインターネットを使うことをやめるだろう。そして、そこまで行かなくてもある程度「有益なものはわずかで、ゴミは大量」という状態になった時点でやめる可能性が高いだろう。つまり、そういうことだ。

スパムメールなどがインターネット上で重罪なのもそれ故だ。 ちなみに、これはこれで経済損失としては非常に大きく、ちょっと近年のデータはないのだがかなり深刻であり、かつ一定以上増加すると社会が麻痺する可能性もあるほどの危険性がある。 そのため、日本では違法でもある。

インターネットにおける罪というのは、倫理とか道徳とか、あるいは国家秩序なんてものとは 全く関係がない 。 インターネットにおける罪はインターネットを殺す行為であり、デマの拡散というのはまさにそれにあたる、ということだ。

タイミングと責任の問題

では社会的な話をしよう。

災害直後というのは非常にデマを呼びやすい状況にある。 人々は不安で、かつ正確な情報の伝達手段を損失しているからだ。

しかも、正確な情報が手に入らないことは人命に関わる。だから、例えデマでなかったとしても「十分に意義のないことは含めないようにしなければならない」というのが前提である。 不正確な情報や憶測によって救助が間に合わなかったり、あるいはどうでもいい内容によって救助が必要な情報が埋もれてしまう、という状況は容易に察しがつくだろう。

だから、災害直後という状況下においては 正しかったとしても、その緊急時に必要とされない情報を挟み込むのは人命に関わる暴挙 なのである。

社会的に見れば、災害直後にこのような発言をしたというのが深刻に問題である。 さらに、「不安を煽るような発言」「根拠を示していない憶測に基づく内容」「断定」とあかんものが揃っている。

まして今回の場合、「災害直後は話が広まりやすく、風説の流布には適したタイミングである」という認識があってわざとやったのであり、すごく悪質である。


  1. これは「インターネットでは」であって、「インターネット上の民意では」という話ではない。

OPPO R17 Pro

まえがき

Zenfone 4 Selfie Proを割ってしまった。 比較的落としたりしても大丈夫な端末だったが、ポケットから落ちて石畳に画面からまっすぐ落ち、広範囲に渡って割れた。

画面が割れた以外の支障がなかったため、全然使っていないという事情もありそのままにしていた。 だが、ビックカメラの格安スマホ安心保証の期間ギリギリであったため、交換と相成った。

内容を見る限りでは「原則修理、修理代が8割を越えたら同一端末と交換」と読めるのだが、実際は交換を前提に運用されているようで、 交換端末について聞かれたし、つまりは同一端末以外へも変更できる、ということだった。

方式としては交換端末から元端末購入時の金額を引く。その上で交換料金を乗せる、という形だった。 元端末より安いものであれば交換料金の5000円だけで済み、そうでない場合は差額を加えることになる。

もちろん、Zenfone 4 Selfie Proは購入時より価格が下がっているし、非常に気に入っていた端末なので交換も候補だったのだが、 その直前に端末を触ってR17 Proに惚れ込んでいたため、R17 Proへの交換とした。 税込価格が8万円近い、ハイエンド帯に入りそうな端末である。プロセッサ的にはSD710となっていて、一応ミドルレンジなのだが、ミドルレンジとしてはかなり高価な端末だ。

ちなみに、基本的な評価としてはSD710は全世代のフラッグシップSoCのSD835と同等、ただしグラフィック性能はだいぶ劣る、ということである。

概要

基本的には使い勝手の悪い最新スタイルの端末だと言っていい。 ディスプレイは6.4インチの有機ELで19:9の2430×1080と、5.88インチからさらに縦長にしたタイプ。 小さなノッチつきだ。

USB Type-Cを持ち、イヤホンジャックはない。 また、DSDSだが、SDカードには対応しない。

このあたりは致命的に使いにくいポイントだ。

一方、SoCこそSD710とミドルレンジに留まるが、カメラはアウトカメラがデュアルで12M+20M、インカメラは25Mという豪勢さ。 レンズもf1.7/2.4/2.0となかなか明るい。

対応周波数帯も多く、バッテリーは1850mAhのものを2機搭載。重めではあるが、全方位に渡って隙がない。

基本的にハイエンドクラスのスマートフォンはゲームユースを想定したものが多いが、 R17 Proの場合カメラを中心として使い勝手や機能部分は惜しみなくハイエンド並のものを投入する一方、処理性能などは過剰なものを入れないようにした 「非ゲーマー向けの最高のスマホを作りました」みたいな感じである。

なお、OPPOといえば「飛び出すカメラ」で一躍有名になったけれど、R17 Proは普通にノッチ。

中国端末では一般的な「AndroidベースのカスタマイズOS」であるColorOSを採用。 なんだか不安を覚えてしまうが、実はこれが「Androidであからさまに欠如している部分」を補うのに非常に有効に働いていて、購入後にOPPOに惚れ込んでしまうポイントになった。

惚れ込んだポイント

驚愕したのがカメラである。

私はYouTubeに動画を上げているが、実はYouTubeの動画撮影はスマホでやっている。 そして、かなり悩まされているのが「ピントが外れる」ことである。 最近のAFは結構賢いと思うのだけど、それでも急に距離が違うものが入ったり、あるいは比較的近いところにあるものが動体だったりするとピントが外れてしまう。 YouTubeの動画は室内撮影なのでより厳しい。埃とかでAFがずれてしまうのだ。

AFが外れたとき、再調整にかかる時間は速いもので2-3秒といったところである。 だが、実際はなかなかピントして欲しいものを掴んでくれないため、延々迷い続けて10秒くらい合ってくれないということも多い。 写真ではフォーカス対象も指定できることからあまり気にならないのだが、動画だと結構痛い。YouTube動画の撮り直しは大変しんどい。

Zenfone 4 Selfie ProもAxon 7も実用的にはなったものの問題を解消するにはほど遠かった。 カメラが良いとされているP20も試したのだが、基本的にはあまり変わらないレベル。フォーカス対象が動いてからもやーっと切り替わる感じで、これはYouTubeでは困るなぁ、という感じだった。

だが、R17 Proは違う。違うというか、もう次元が違う。 ピント合わせに必要な時間は長くて0.3秒といったところ。 遠くを写している状態でカメラの前に手をやると、マクロ撮影になる距離でなければ、もうずっとピントが合っているように感じる。 そこから手を抜くと手を抜いている途中でもう後ろにピントが合っている。 本当に異次元のAFで、これに惚れ込んでほぼこの一点で購入を決めてしまった。

機能別

綺麗だけど埃の激しい画面

画面は非常に綺麗である。貼り付け済み保護フィルムが色々やさしい。

サイズは6.4インチということでなかなか厳しい。 私はポップソケッツを真ん中右よりにつけているけれど、持ち替えないと端っこには微妙に届かない。傘を持ったまま完全に操作できるかというと無理である。 私の手の大きさは男性としては標準的なので、手が大きめの男性ならポップソケッツを使えばいけるだろう。女性にはかなり厳しいと思う。 なお、バンカーリングでは支えるためにスマホのどこかに手を接触させる必要があるから、かなり手の大きい人でも無理だと思う。はしっこにつけて、第一関節がかかるようにするくらいか。 両手持ちの人なら問題はない。一方、スマホをホールドするタイプの人は私の手のサイズだと画面真ん中くらいまでしか届かないということを考慮する必要があるだろう。

注目すべき点として、「オート輝度とブルーライトカットフィルターが実用的」ということが上げられると思う。 オート輝度は自分の顔が影になるなどしてコロコロ輝度が変わってしまってみづらいために、ブルーライトカットは赤みが強くなりすぎるために使い物にならないと感じていた。 だが、R17 Proのオート輝度は適切な値をキープしてくれるし、ブルーライトカットは白は黄色っぽくなるものの他は自然でほとんど気にならない。

ただ、欠点として埃を非常に集めやすい。 物が多く掃除してはいるものの埃が舞っている私の部屋では常にホコリまみれになる。 外ではあまり気にならない。物が少なくて埃を取り切れる家なら問題ないと思う。

Zenfone 4同様にスクリーンオフの状態で時計を表示する機能がある。 デジタルクロックなのでZenfoneよりも実用的。

全画面表示のコントロールとして、ノッチ部分を除外する機能がある。 ノッチを考慮していないアプリでの全画面表示で困らない。

PVCケースはつけたいかも

重量はちょっと重めで、厚みは控えめ。だが、カメラが出っ張っている。 このため、付属のPVCケースが保護に有効で、久しぶりに使っている。

素の状態ではガラスなので滑りにくいが、やっぱり埃を集める。 そして、マット加工されているミストグラデーションは気にならないが、エメラルドグリーンは大変指紋が気になる。

基本的に最大側に振り切れているボリューム

音量も輝度も、最大側が極端に大きい。めちゃくちゃ明るいし、爆音である。

最小値は適切に小さい。だが、値全体としては圧倒的に大きく、「控えめな値」を求めるのであれば下1/4くらいで調整することになる。

認証

指紋認証はスクリーン上にある。 画面OFFでもGを関知し、かつ暗くなければかっこいいアニメーションで指紋認証ポイントを教えてくれる。

指紋認証の精度と速度は普通。Zenfone 4 Selfie Proの認証は絶品だったので、その意味では不満。 また、手が濡れていると全く効かない。

超絶性能のカメラを利用した顔認証は非常に強力らしいのだけど、好みの問題から私は使っていない。

PINは標準で6桁。 わかりにくいが、設定時に「その他の暗号化モード」を選択することで

  • パターンコード
  • 4桁の数字パスワード
  • 4-16桁の数字パスコード
  • 4-16文字の英数字パスコード

から選ぶことができる。

ちなみに、珍しい機能として、メールアドレスを登録しておくとパスコードを紛失した際にレスキューできるらしい。

完璧すぎるカメラ

ちょっとおもしろいポイントとして、センサーが4:3である。 最近のスマホは16:9でしか写真が撮れないのでセンサー自体16:9なんじゃないかと思うのだが、センサーが4:3で4:3の写真が撮れる。 ちなみに、画面比率に合わせたものも選択できるのだが、この場合短辺側がクロップされる。

画角としては4:3なため一般的なスマホと比べて短辺側は広い。一方、長辺側は狭く、現実的な使い勝手としてはちょっとナローな感じがする。 ここはマイナスポイントかもしれない。

前述のようにAFが化け物じみている。 ここまでAFが速いと世界が全く違う。夢のようだ。

写真は文句なしに美しい。 普通の写真で文句つけるのは、カメラにかなり詳しい人でないと難しいと思う。私は、比べればわかるだろうけども、単独で見せられても完璧としかいいようがない。 ちなみに、比べても私がもっているあらゆるカメラより綺麗に映る、としか言えない。

光学手ブレ補正もついていて、シャッターを切るのもとても速い。かなり速く動かしながら撮ってもぶれない。 マニュアル撮影も可能で、ISO感度含めてちゃんと制御できる。シャッタースピードもコントロールできるから流し撮りも可能。 背景ぼかしの可能なポートレートモードもある。

暗いところではシャッターを押した後ホールドするように求められる。 「シャッター音がしてから3秒間」なので、ちょっと間違えやすい。 「夜間」を選択すればウルトラナイトモードとなり、電飾も綺麗に再現できるAI機能つき夜景モードとして撮影できるようだ。

なお、12Mpxのほうが主で20Mpxが補助。切り替えは自動、とのこと。

セルフィに関しては「顔を好みに調整する」というSNOWみたいな機能がある。ただし、あまり極端にはならない。 かなり盛れるけれど、盛り度合いでいえばASUSのほうが上。まぁ、Zenfone 4 Selfie Proはセルフィスペシャルなスマートフォンだし、そこでは負けられないでしょう。

動画はHD/FHD/4kと選択肢が狭く、独立してH.264/H.265を選択できる。 FPSの指定はできない。 スローモーションは90FPSか180FPSだろうか。1/3倍速になる。

動画に関してはちょっと特徴的な部分がある。

まず、光量が十分な環境下では常に超絶AFで無双できる。 だが、暗いととても明るい部分だけが写り、全体的に黒つぶれしてしまっているようにみえる。 しかし、その状態でもAFは常に適切に捉え続け、コントラストとブライトネスを調整すると全く潰れていないのが分かる。 Axon7は全体的に明るいが、コントラストやブライトネスを調整しても見えないものは見えない、全体的に白っぽくなるだけという感じだ。

そのため夜間の動画撮影も調整前提であれば強力なのだが、蛍光灯がとってもちらつく、という問題が発生する。

性能とゲームスペース

基本的にバッテリー持ちはよく、SuperVOOCのチャージの速さもあってバッテリーに関してはかなり強い。 バッテリー持ちの良さの一因として、そもそも性能がかなり抑えめ、ということがあるようだ。

これは、「普通はそんなに性能がいらないはずなので、性能は抑えめにしつつ、ゲームスペースに登録することでフルパワーで動作させることができるようにする」という設計に基づくようだ。 これは非常に合理的かつ実用的。ただ、ウェブレンダリングは重く、プロセッサパワーを非常に必要とする一方、バッテリーへの影響も大きいので、ブラウザをゲームスペースに入れるかは悩ましいところになりそうだ。

RAMは6GBだけど、いつも通りのこととしてRAMが増加しても空き容量はそんなに増えない。実際、初期状態で空きメモリとしては3GBに届かない程度である。

フラッシュメモリは128GBで、ユーザー利用可能なのは108GB。

バッテリー節約機能は「ボタン一発、バックグラウンド通信OFF」とシンプルかつ実用的。 全体的なチューニングとしてもAndroidとはまた違い、より使いやすく、それでいて割と節電も効いている感じだ。 ただ、ベースのAndroid 8.1と同じくDoze下でアプリの通知を落としてしまう。LINEの通知もこない。比較すればやや届きやすい気はする。実際、AndroidではDoze下でDiscordが届かなくなっているけれど、ColorOSは届けてくれる。

執拗なまでのセキュリティ機能

購入してから惚れ込み、「サブもOPPOにしようかな」と思ってしまったのがこの機能だ。

アプリの権限

これ自体は普通なのだけど、Android標準のアプリごとの権限ではなく、「権限からアプリを探す」ということができる。 すごく使いやすい。

フローティングウィンドウのブロック

ポップアップを防げる。思わぬタイミングで広告を挟んでくる鬱陶しいアプリを抑制できる。 これゲームとかによさそう…

個人情報で空を返す

「最高じゃないか!!」と思ったのがこの機能。

「通話履歴」「連絡先」「メッセージ」「イベント情報」について(もしくは私が権限を要求するアプリを入れてないだけのその他について)アプリを指定して保護することができる。 保護されていると、アプリがその情報を要求したときに本当の情報ではなく空の情報を返すという。

つまり、例えばSkypeは連絡先情報を要求するし、これをブロックすることはできない。 かつ、勝手にSkypeと紐づけて使用するし、保存もする (アプリを消しても関連付けられたままになる)。 だが、この機能を使えば、Skypeに対して権限としては許可しつつ、実際の連絡先にはSkypeはアクセスできない状態にすることができる。

紛失端末を探す

捜索機能がGoogleとは別口で使えるようになっている。 ちなみに、デフォルトでオン。

決済アプリの制限

アプリによって勝手に決済されてしまわないようにするもののようだ。 決済するアプリを私は何も入れていないので使っていない。

着信拒否

着信とメッセージをそれぞれ独立して拒否することができ、ブラックリスト/ホワイトリストも利用可能。 拒否した場合は通知にも表示しないという機能もある。

偽基地局のブロック

基地局になりすましたジャックを防ぐものらしい。

アプリの暗号化

「最高じゃないか!!」と思ったの機能その2。

アプリ保護機能だが、OSレベルで動作し、認証しなければアプリは開くこと自体できない。 また、保護されているアプリはアクティビティからも隠される。

さらに、アプリ保護に使うパスコードはロックに使うものとは別に設定できる。すごい。

キッズスペース

アプリの制限、利用時間の制限、課金の制限が可能。 すごい。子供に持たせるならあってもいいかもしれない。

隠しファイル

写真、オーディオ、文書、その他に分類し、通常は見えないようにすることができる。

この機能のメニューからアクセスすることもできるし、標準アプリの「写真」から選択する、ということもできるようだ。 単に見えないだけでなく、認証が必要になる。

その他

  • 安全なパスワード用キーボード
  • セキュリティ機能使用時のスクリーンショットの抑止
  • バックグラウンドで撮影・録音の禁止

の機能がある。ちなみに、LINEのパスワードはパスワードキーボードが出ない。LINEは安全な入力になっていないらしい。

なお、ColorOSの要求する権限(特にホームアプリ関連)がちょっと多い。 この点は結構気になるけれど、OPPOに限ったことではないからあまり選択の余地はない。

プリインストールアプリもがしがし消せるのは嬉しい。

通信関係

アプリごとに「WiFiとモバイルデータ」「WiFiのみ」「ネットワーク禁止」を設定できるのはセキュリティ的にも強い。 また、モバイルデータを細かなポリシーに基づいて抑制する機能もある。

月ごとではなく、1日のデータ使用量に対する警告も可能。

NFCは使えないよ、と公式ページにはあるけど、機能としてはある。

テザリングのパスワードが初期設定は明らかアウトなものになっているので注意が必要。

組み込みでDLNA機能がある。

おやすみモード

手動、またはスケジュールでオンにできる。 Androidにも搭載されている機能だが、ColorOSのものはより細かい。

まず、メッセージあるいは着信を「すべて禁止」「連絡先に登録しているもののみ」「お気に入りの連絡先」のいずれかのものは通すようにできる。 通知の許可/不可ができる。そして同じ番号から3回電話があったら鳴るようにできる。

音関連

外部メモリに対応しておらず、ヘッドフォンもUSBであることから「ない」と考えていたのだが、音質は非常に良くて考え直すほどだ。

付属ヘッドフォンはAppleタイプ。外れやすくて好きではないが、音はかなり良い。

なお、サウンドエンハンス機能としてReal Original Soundが載っているけれども、標準の「音楽」アプリでしか使えないことを含めて微妙。 音楽プレイヤーは普通に使いやすくてよろしい。

ヘッドフォンモニター機能があり、スピーカーとヘッドフォン両方から鳴らすことができる。

収録されている着信音、通知音がAndroidと違う。 Androidよりもセンスがあり、使いやすくてこれもまた良い。

入力関係

入力はGboard。好きなのを入れてもいいと思う。 Gboardを使う場合、英語Qwerty入力ができないため、英語を有効にしておくと言語切り替えで利用できて便利。

プリインストールアプリ

OperaとFacebookとWPS Officeくらいだろうか。目立つのは。あとはAquaMail.

機能としてはコンパスがあるのが珍しい程度。音楽や写真アプリなどはなかなか使いやすい。

ホーム機能

ドロワーのないiPhoneタイプ。 これはさすがにZenfoneに搭載されているZenUIの出来には到底及ばない。

ホーム画面の編集はロングタップではなくピンチイン。

スマートサイドバーという、補助ナビゲーションを表示する機能があるけど、大きい画面で一部分から引き出すものなのでちょっとやりづらい。特にケースに入れてるととてもやりづらい。

通知

ノッチの都合なのか、通知アイコンは出ない。 画面オンにせずにアンロックできる都合から、通知に気付かないことが少なくない。

ColorOS独自な部分として、ネットワーク速度を表示したり、バッテリーアイコンの中にバッテリー残量を表示したりすることができる。

ハードウェアUI

ボタンはオンスクリーンで、ファーウェイやAndroid Oneと違って基本的には表示しっぱなしで、全画面時に消す仕様。

電源ボタンが右、音量ボタンが左で、推し間違えは少なく、固定もしやすいが、片手でスクリーンショットはできない。

指紋認証はオンスクリーン。位置がやや微妙で、普通にポケットに入れようとしたときなどに触ってしまうのが残念な感じ。

スピーカーは下部でモノラル。インターフェイスはUSB-Cのみ。マイクは(多分)上下。

カメラにZenfone 4 Selfie Proのような内側ライトはない。

その他

マルチアプリ機能であるClone Appに対応している。 ただし、LINEで試した限りあまりうまくいかなかった。フローティングウィンドウが延々出たりする。 ただ、ASUSのdual appのように「LINEのトークのバックアップができない」「共有が動作しない」などの不具合があるため、dual appよりは実用的。

ダウンロードの管理ができるのは結構便利。高速ダウンローダがあるとかではなく、ダウンロードしたファイルをマネジメントできる。

「手順」という形でサポートの手引きが見られる。これは超親切で感心した。 AXONにも似たものがあるんだけど、こっちはちょっと使いにくい。

デバイスの電源スケジュールがオン、オフ共に設定できる。 これもなかなか便利。

バリアフリー機能もなかなか魅力的な要素が多い。特に「モノラル出力機能がある」のはとても親切。

テザリングはWi-Fiテザリングのほかにパーソナルホットスポットという機能があるけど、違いがわからない。

アクティビティはロックが可能で、ロックしているものはclean allの対象外になる。 ただし、「最初からロックされるアプリ(LINEなど)がある一方、手動でロックしたアプリは次回起動時にはロックされていない」という仕様でやや微妙。

結び

カメラのAFに惚れ込んで買ったのだけど、使ってみるとColorOSの魅力にやられてしまった感じだった。

特にアプリの暗号化は強力で、重要な情報にアクセスできるのにロックできないアプリに対する保護が実現するのは大変良い。 個人情報を空で返す機能も、「個人情報へのアクセスが嫌」という理由で私は連絡先も使っていないため、この機能があることで実用性は一気に増した。

もちろん、USB-Cしかないこと、SDカードに対応していないことなど不満はあるが、それでも「買ってよかった」と思える逸品だった。 ミドルクラスでもかなり高めの製品だけれど、その価値はあると思う。

また、従来Zenfone 4 Selfie ProとAxon 7で棲み分けが難しかった(カメラ, ディスプレイ, 音楽機能がいずれも甲乙つけがたかった)のだが、今回大きくキャラクターが変わったため棲み分けが簡単になった。 2台持ちする人であれば、AQUOS R2 Compactあたり1と組み合わせると欠点が補えて良いと思う。 1台持ちの人であればちょっと癖が強くて苦労するかもしれない。R17 Proに合わせた運用をすればいいだけだが、2台持ちすればR17 Proの不得手な部分を補えるので運用が楽になる、というのは覚えておくといいだろう。


  1. コンパクトで軽量、ゲームに適したSDM845、SDXC対応、防水防塵、広角レンズ、3.5mm端子とR17 Proにはない機能が揃っている。

Linuxデスクトップ環境の比較

Linuxデスクトップ(Unix系デスクトップ環境)の使い心地というのは使いこんでみないとコメントもできないものなのだが、なかなかその特性を理解するまでそれぞれを使い込むのも難しい。 特にまだLinux歴の浅い方はどれを選んで良いのかわからないこともあるだろう。

そこで現行のデスクトップ環境からメジャーなものについて、私が感じる良い点、悪い点をまとめてみた。 あくまで私の視点なので、異なる意見もあるだろうが、そこはあくまで1ユーザーの意見とご了承願いたい。

また、MATE, Deepin’, Pntheon, Budgie, Lumina, LXDE, LXQtなどの他のデスクトップ環境、あるいはEnlihgtenment, fvwm, i3, awesomeなどの他のウィンドウマネージャがあることは承知しているが、私が普段使っていないのでコメントするレベルにはないことも、併せてご了承願いたい。

GNOME

良い点

  • Waylandに最も良好なフィーリングを見せる
  • スクリーンショットツールがとても使いやすい (ただし設定はgsettingsコマンド)
  • ウィンドウボーダーのデザインが豊富で、良いものが多い
  • ランチャーがコマンド実行になっており、検索前提のアクティビティ機能と相性がいい
  • Gnome Keyringは様々なキーをいい感じに管理してくれて使いやすい

悪い点

  • 設定の大部分が隠されており、テーマ設定などの基本的な設定もできない。また、壁紙もコマンドを打たない限り$XDG_PICTURES_DIR直下の画像ファイルに固定されている
  • ウィンドウタイリングが左右にしかできない
  • ウィンドウフィッティングが弱く、表には設定もない
  • Nautilusで右クリックにおけるアクションメニューが簡単に設定できるようになっていない
  • Alt+マウスドラッグによるウィンドウ操作ができない
  • メニューが非常にわかりづらく、メニューが少なすぎて必要な機能を満たさない
  • 「1画面しかなくて、1画面に1アプリしか表示しない」が基本なので、ウィンドウはクローズボタンしかない
  • アクティビティ機能はプログラムをカテゴリ分けしてくれないので、探すのが非常に辛い
  • ウィンドウスイッチャがなく、常にアクティビティから切り替えるかタスクスイッチャから切り替えることを求められる。カレントウィンドウのメニューは表示されるが、マルチディスプレイの場合はプライマリディスプレイ以外無視される 
  • 設定がホームディレクトリ以下になく、バックアップしづらい

捕捉

私はGNOMEが好きではないので、すごく否定的な意見であると考えてもらっていい。 「Linuxなら出来て当たり前だったことをわざわざできなくしている」ことに私は好感を持てない。

Gnomeアプリケーションにはいくらか魅力的なものもあるけれど、デスクトップコンピュータ、とくにマルチヘッドディスプレイや、大画面で使うのに適したものだとはとても思えない。

Gnomeはパソコンよりもタッチデバイスを優先しているのだと感じるし、パソコンもせいぜいが今風なラップトップのみを想定しているといったところだろう。 そして、様々な機能を要求に応じて使いこなす努力するユーザーではなく、機能を使う気がなく、機能を与えてほしくないルーザーのみに親切、という印象である。

ただ、それは解消不能な一部の問題(例えばウィンドウタイリングやAltマウスイベント)を除けばgconfなどによって解消することができ、 およそ「Windowsでレジストリをいじる」のと同じレベルで操作することにより、ユーザーによっては満足できるものに仕上げることもできるだろう。

Cinnamon

良い点

  • 非常に使いやすいウィンドウタイリング。 Super+カーソルで「現在の状態を基準にカーソル方向へタイルする」という挙動。また、タイルした状態でリサイズもできる
  • ウィンドウタイリングしたあとウィンドウを移動すると元のサイズに戻すようになっている。これは、タイル状態でリサイズした場合も同様で、タイルにウィンドウサイズのステートが影響されない
  • 軽い。 ハードウェアアクセラレーションが効くためXFceと比べても格段に軽い
  • ウィンドウフィッティングが設定可能で、かなり使いやすい。タイルしたウィンドウに対してもフィットするため大量のウィンドウを並べるのも楽
  • Alt+左ドラッグ(move), Alt+中クリック(windows menu), Alt+右ドラッグ(resize)全てに対応している
  • 設定項目はやや少ないが、必要なポイントは抑えていて「ほどよい曖昧さ」になっている。設定が大変ではなく、かつ必要な設定はできる傾向がかなり強い
  • Gnomeのメリットだったスクリーンショットと鍵管理はGnomeと同じものを使用しており、同じメリットが得られる
  • Nemoアクションがiniファイルになっていて、結構書きやすい (ただ、現在ちょっとバグってもいる)
  • ウィンドウラベルのマウススクロールに対して細かな設定が効く。アルファ設定も可能
  • Nemoが単独で動作し、軽いファイルマネージャでありながら、gvfsによるマウントにも対応していて使いやすい
  • Alt+F1でワークスペース選択になるのが便利。数字キーで選択できる
  • マルチヘッドディスプレイでフルスクリーンにしているとき、パネルは「パネルがある画面上でフォーカスされているのが他のウィンドウであるときのみ表示する」という理想的な振舞い。フォーカスウィンドウはフルスクリーンウィンドウより前にくる
  • 選べるデスクトップアニメーション
  • 純粋なコマンドラインのランチャと、検索可能なメニューの組み合わせ
  • 左右へのパネル配置に比較的強い
  • 合理的な「フォントはDPIではなく倍率で設定させる」
  • DPのプラグアンドプレイ問題で「復帰できない変更をされる問題」が比較的少ない
  • ボリュームアプレットがマイクのミュートコントロール、デバイス選択、プレイヤーコントロールまでできる便利設計
  • フォント設定機能がフォント数が増えても軽く、使いやすい
  • ファイルダイアログが未選択状態でキータイプを始めると直接パス入力できる仕様
  • Conkyの表示が一番安定している
  • ウィンドウスイッチャからQで直接ウィンドウクローズが可能

悪い点

  • 通知を1件ずつ表示するため、大量の通知がある場合いつまでクリックしても終わらなくなる
  • 通知の有効期限をスクリーン上ではなく通知エリア上の時間として扱う。これは、恐らく正しくない
  • 壁紙がウィンドウごとではなく共通である。設定が楽、ディスプレイ認識でおかしなことにならないというメリットはあるが、残念には感じられる
  • ウィンドウデコレータがMetacityベースでデザインがあまりよくない
  • アプレット機能があるものの、動作しないものが多く、ほとんど役に立たない
  • 起動がやや遅い

捕捉

基本的に「すごくいいバランスで、うまい具合に作られている」のがCinnamon。 機能豊富というわけではないのだが、GNOMEやKDE Plasmaのように主張をぶつけてくる感じではなく、「どうあるのが自然か」「どうなっていれば使いやすいか」ということに向き合って作られている感じがする。 (ただ、Cinnamonはissue reportに対して割と対応は冷たいのだが)

ほとんどの場合要求を満たすことができ、完全ではないが不満というほどではないという状態を作るのがうまい。 至らないところもあるが、使い勝手なら最高だと思う。私は何に移ってもCinnamonに戻ってきてしまう。

ややいまいちだったウィンドウスイッチャは、Windows7以降と同様のアイコンスタイルのものが導入されて使いやすくなった。 グループに対してはホバー時だけでなくクリック時にウィンドウリストを表示する機能もあるが、これはまだbuggyである。 垂直表示を有効にしていると、ウィンドウグループを縦に表示し、さらにそのウィンドウから派生したウィンドウは水平に表示するという器用さを見せる。 懸案だった「.desktopファイルに書かれている情報を使ってくれない」という問題も解消してくれている。

ClutterとNemoの出来の良さが圧倒的で、総じて非常に使いやすい。派手な機能はないが極めて実用的だ。 Cinnamonの欠点を探してみたのだが、これといってあまり見つからなかった。以前はいくつかあったのだが。それが戻ってきてしまう理由かもしれない。

KDE Plasma

良い点

  • 非常に充実したアプリケーション群でクオリティも高い
  • 非常に充実した設定項目。特に電源管理が優れている
  • KIM Panelが格段に使いやすく、Fcitxのウィンドウも統合されていて入力が快適
  • Alt+マウスドラッグによる操作をカスタマイズできる
  • デザインが良い
  • KDEパネルは機能が多彩で、ウィジットも強力
  • 0.1倍単位のUIスケーリング。Gtkアプリケーションにも対応する
  • 検索のみではあるもののランチャもメニューも強力な検索で使いやすい
  • KDE Walletはウェブブラウザのパスワードを一括して管理してくれるので安心感がある
  • 設定ファイルが素直にホームディレクトリ以下にあるためバックアップしやすい
  • Qtの利点を活かした非常にスムーズなスクロール
  • ディスプレイ接続時のアクションが良好で、プレゼンなどでプロジェクターを使うときにも使いやすい
  • ディスプレイを「重ねて配置」できる
  • ウィンドウフィッティングが非常に素晴らしく、ピタッとウィンドウを並べることができる
  • フォントレンダリングに手が入っているのか、ちょっと綺麗
  • 通知の扱い方が適切で使いやすい

悪い点

  • やや不安定
  • サイズの異なるディスプレイを並べると、ディスプレイ位置がおかしくなったり、パネルを失ったり、壁紙を失ったりする
  • ディスプレイの再接続時に本来のディスプレイ設定に復帰しない
  • よくアイコン位置がおかしくなる
  • プラズマにログインしてからログアウトし、再度プラズマにログインするとスケーリングがおかしくなる
  • Balooを有効にしているとキャッシュファイルなども画像に含められてしまい困る上に、inotifyの上限に到達してもさらにファイルを追加するためシステムが終わる
  • AkonadiやKDE PIMは便利ではあるけど、「いらないことをする」感じも強い
  • KDE WalletがGnome Keyringのように暗黙にSSHエージェントのように振る舞わない
  • 設定が独特で、XDG標準を遵守しないし、XDGディレクトリもあまり尊重しない
  • Dolphinはアクションを追加するのも面倒で、XDGディレクトリを無視し、ブックマーク機能はない
  • ウィンドウタイリング後にウィンドウを移動すると、ステートはタイルされていないことになるが、元のサイズには戻らない
  • 壁紙の設定が面倒。フォルダの追加は知識が必要で、全部まとめられるので

捕捉

理想は高く、理想に届かないKDE Plasma。 KDE Applicationsに満足するか否かが分かれ目になる。

ウィンドウフィッティングはCinnamon以上に良好で、ウィンドウを並べるのは得意。 ただし8方向タイリングはショートカットキーの設定が必要になる。 一応、マウスでエッジに持っていくとタイリングしてくれるのだが、位置が割と狭くてやりづらい。

大きな欠点だった「等幅フォントにデュアルスペースフォントが設定できない」は、spacing >= 90にするのではなく、spacingを無視するオプションを加えて対応している。

うまく噛み合っていれば使いやすいのだが、噛み合わないことが多いKDE Plasma。 状況がハマれば使いやすいため、私はラップトップではKDE Plasmaを使用している。

なお、KWalletでブラウザの鍵を管理すると、ブラウザはこれまで管理していた鍵を捨ててしまう。 逆にブラウザに管理させるとKWalletで使えなくなる。だから他のデスクトップと行ったりきたりするのには最大の障壁になる。

systray問題として深刻だったsniについても、現在はおよそ問題のない状態になっているようだ。

特にスケーリングの自由度は大きなメリットと言っていいだろう。 電源管理の柔軟さと併せて最新のラップトップには適しているように感じる。

KDE4時代の癖のあった特徴的な機能は下げられている。そのため、積極的にKDE Plasma workspaceを使う理由を損ねたという印象もある。

相変わらずbuggyな部分も残念だ。Balooは非常に振る舞いに問題があり、オフにしておくのが無難だろう。

XFce4

良い点

  • Alt+左ドラッグとAlt+右ドラッグに対応
  • パネルウィジットのアプリケーションメニューが独自メニューを設定できるため、引き出しとして使用できる
  • 「ランチャー」ウィジットは副項目を設定でき、やっぱり引き出しとして使用できる
  • XFce4 Terminalの使い勝手が良い
  • やたら積極的で便利な「透明度」設定。透明ウィンドウ好きにはたまらない
  • ThunarがSFTPに対応している
  • ディスプレイの「ブランクスクリーン化」と「電源off」が分けられていて、DPプラグアンドプレイに悩まされている場合は便利
  • 自動起動にそれとわかるように他のデスクトップ環境のものが選択できるようになっており、Gnome Keyring SSH Agentを使うということもできる
  • 8方向タイル可能。ただしタイルのショートカットキーは全く設定されていない
  • デスクトップ右クリックでデスクトップコンテキスト(アプリケーションメニューつき)、中クリックでウィンドウリストと結構便利
  • アプリケーションファインダーがコマンド実行で候補検索を含み、展開すると(Alt+F3でこの状態でスタート)メニュー検索もできるようになった
  • Whiskerは簡単にリサイズできる
  • Mugshotが実は結構便利
  • デスクトップにウィンドウリストを表示することもできる
  • ウィンドウスイッチャがグリッド状に表示されるため選びやすい
  • パネルの設定が器用で、高さを含めるかどうか、ホバー時で透明度を変えるか、隠すかなど設定可能。「Dock風」と「タスクバー風」を使い分けられる仕様
  • 壁紙の設定がモニターごとである上、「設定ダイアログをモニター上に動かせばそのモニターが設定できる」親切設計

悪い点

  • アイコンラベルのサイズは固定で、アイコンの間隔も固定。ちょっと長い名前のフォルダは簡単に隠されてしまうし、隠されないように設定すると
  • Bluemanが初回起動時だけXDGディレクトリを拾うため、XDGディレクトリを変更すると毎回エラーを出す
  • ウィンドウフィッティングは一応存在し、リサイズ時にも効くのだが、非常に弱い。設定もできない
  • 通知がいくつでも出してしまう上に、閉じても表示した位置に表示しっぱなしで大量に出されるととても困る
  • ウィンドウタイリング後にウィンドウを移動すると、ステートはタイルされていないことになるが、元のサイズには戻らない
  • パネルがデスクトップの大きさとして除外されない(xfwm4は除外できる)ので、デスクトップアイコンやConkyがかぶる
  • ファイル選択ダイアログがGnomeと同じものになったため、ファイルをパスで一気に入力することができなくなった
  • アプリケーションファインダーがフォーカスロックしないため、複数起動してしまうこともでき、さらにフォーカスを失うことがあるため「あれっ」となって複数起動してゴミが残ることが多々ある
  • フルスクリーンにしているとき、フォーカスしているアプリ以外はパネルがウィンドウより前にきてしまう (マルチヘッドディスプレイでのみ発生する)
  • 標準のボリュームアプレットがない (外部プログラムとしてはPulseAudioアプレットがある)

補足

XFce4になったときからずっと「ちょっとずれてる」「いい感じなのに、対応したにもかかわらず痒いところに手が届かない」を続けているXFce。

だが、Gtk3化の過程で大胆にチェンジした。 アイコンラベルとか、アプリケーションファインダーのフォーカスとか、微妙に「XFceだなぁ」と思うところは残っているものの、機能的には遜色ないどころか、他の環境を凌駕するところまで到達している。

Manjaroでは18.2からついにXFce4 Gtk3がメインになった。 使い物にならなかった時期が長かっただけに、ようやくという感じだ。 だが、

  • thunar-archive-plugin
  • thunar-volman

についてはGtk2を引き続き標準としている。 thunar-volman-gtk3はextraとcommunityそれぞれにバージョン違いがあるちょっと困った状態だ。

ウィンドウデコレータがMetacity相当になり、Cinnamonと同じものを使えるようになった。 今までちょっと偏りがあって使いにくいものが多かったので、非常によくなったし、デフォルトのものが結構スタイリッシュにもなった。

基本的な方向性はCinnamonやMATEに近い進化だと思う。 使い勝手が劇的に向上し、他のデスクトップと比べ見劣りするという印象を払拭した。 Gtk3になったため「軽い」という特徴は損なわれたが、最近はアプリケーションのほうが重く、Gtk2を採用するアプリケーションも少ないため、正直デスクトップの重さというのはそもそも感じにくい。 むしろ処理が速くなって快適になったくらいだ。

中学生のための英語 all, any, each, every の違い

感覚的にわからない?

コンピュータ系のドキュメントでは頻出し、しかも決定的キーワードとして登場するall, any, some, each, everyの5語。

実際の動作と照合すれば意味は明らかなのだけど、英文を読む機会が少ない人が多いのか、これに関して「否定ではany」とかよくわからない解説がされているものを見かけることがある。

そこで、これらの意味合いの違いと使い分けについてサクッと解説しよう

allとany

allはすべて。anyはいずれかひとつ。

通常は全く異なる意味なのだけど、否定になると意味はかなり近くなる。

否定であればallは「全て ない」であり、anyは「ひとつも ない」である。

ただ、実際のところ否定のallという言い方はちょっと曖昧。 意味としては “no all instruments”といったら楽器はひとつもないのだけど、noがallを否定していて「全てはない」と言っているかのようにも思える。

だから、「ひとつとしてない」場合はanyを使うほうが普通で、もしくはnoなんちゃらか、nothingなんちゃらになる。

あんまり見かけないけれど、someの否定だとanyと一緒なんだけれど、ちょっと弱い。 探せばあるのかもしれない。とりあえず見当たらない程度のニュアンス。

anyとsome

否定でないのであれば(肯定形という言い方は変なのであまりしたくない)anyは「いずれか」、someは「いくらか」。

anyの場合、ひとつでもあればOKで、いくつあるかは全く気にしない。 I want any girlfriend. といったら「誰でもいい」。

someの場合、少なくともひとつ、あるいはそれ以上。 I want some girlfriend. といったら最低限ひとりは欲しくて、できればハーレムにしたいということになる。

また、anyoneの場合本当に誰でもいいのだけど、someoneと言った場合該当するoneは限定されている可能性が高い。 anyoneの場合不特定多数の中の誰かであり、someoneといったら特定の集合の中の誰かと考えていいだろう。 もちろん、anyone自体に前提として条件がかけらる場合もあるのだけど。

allとeveryもしくはeach

allは全体、everyとeachは個々。

だから、allが導く文は集合名詞(冠詞なし)か複数形なのだけど、everyやeachは集合あるいは複数のeveryやeachが導く文は個々になる。

現実的には人に対してはallを使うことはあんまりない。 それは主語が大きい人になってしまう。 ただ、物に対しては言う。

All pieces are painted with black ink. みたいに。

eachやeveryだと続く文は単一なので

Each pieces has different figure. みたいな感じで三人称単数形が登場する。

eachとevery

everyのほうは全てに共通する意味合いが強く、eachはより個々。

everyのほうは個々がどうであれそうであるという感じだから、母数が変わっても事情は変わらない。 例えば「まいにちまいにちぼくらは鉄板の…」であれば、例えそれが10年20年と続いたって変わらないのだという意味が強いので、“evryday, everyday”になる。

じゃあ、「合宿中は毎日カレーだ」だとどうだろう? まぁ、実際はこれもeverydayになるんだけども、これが月曜日はポークカレー、火曜日はシーフードカレー、水曜日はキーマカレーで「毎日カレーのくせに内容変えてきやがる」みたいな話だと「それぞれの日がそれぞれにカレー」なのでeach dayという言い方でわざわざ強調もできる。

everyの場合、そうなる必然性がある。個々の意思ではなく、なんらかの共通要素によってそうであるということであり、個々がどうであるかということを考慮する必要はないのだ。 一方eachはそれぞれがどうしたか、どうであるかの話であり、その内容は個別になる。

先の例である Each pieces has different figure. だと個々違う形を持っている、つまりそれぞれに形状があるという話なのでeveryにはならない。どのピースもそれぞれが違う形状を持ったという話だからだ。 これが、同じ型を使っているとかで個々の意思とは関係なくそうなるべくして同じ形を持っているとしたら Every pieces has same figure. なる。