Google Chromeが7月のversion 69でSSLを要求

どうなるのか

Google Chromeが7月にSSL(HTTPS)でないサイトに対して警告するようになる、という話を聞いたので、現在Developer Buildのversion 69をインストールして試してみた。

内容はIT Mediaの記事が正しかった。 つまり、

  • 従来は「HTTPSサイトは表示」だったものを「HTTPサイトは表示」に変更
  • version 70からはHTTPサイトでのフォーム入力時は警告表示

日経BPの記事をみると、まるでSSL署名が正しくないときのような警告がなされるかのように読み取れるがそんなことはない。

話はこういうことだ。

もともとはHTTPが標準だった。HTTPSであることは特別であり、故に「保護されています」と表示していたわけだ。 しかし、今後はHTTPSが標準であるため、いちいちHTTPSであることは強調せず、HTTPであることは逆にリスクがあることを示す、というわけだ。

この変更は正しいと思う。 対応した環境でブラウジングしているのに、HTTPではなくHTTPSであることで困る、ということは考えにくく、HTTPSであることに対してわざわざ注意を引く必要はない。 むしろHTTPであることはリスキーな状態であり、注意を示しておくべき状況だ。 特にフォーム入力を伴うときは警告すべき状況だといっていい。

状況 現在 version 69 version 70
HTTP 表示なし 「保護されていません」(グレー) 「保護されていません」(グレー)
HTTP + フォーム入力 表示なし 「保護されていません」(グレー) 「保護されていません」(赤)
HTTPS 「保護されています」(緑) 鍵マーク(グレー) 鍵マーク(グレー)

極めて正しいように見える。

GoogleがLet’s Encryptを推進したこととも整合性がとれている。

ただ、それなら「スキームなしでアドレスを入力したときにHTTPでアクセスする」ということはやめるべきだし、 むしろ「http://と指定した場合でもHTTPSを試行する」べきではないのか。

どうすべきなのか

これからは明確にHTTPSが標準となっていき、現在HTTPSに対応していないウェブサイトは「リスキーである」という認知が進むだろう。 これは、事情がわからないユーザーがHTTPの「安全でないサイト」を避ける可能性があるということを含んでいる。

  • HTTPSに非対応はもはや論外。早急に対応すること
  • HTTPSトライはしてくれないので、レガシーデバイスを切り捨てるならHTTPアクセスは301を返すべき
  • HTTPS強制にするにしても、HTTPアクセスを許容するにしても、ヴィジターへの説明はしたほうがよさそう

一応、Mimir YokohamaではHTTPS強制で、HTTPはサブドメインで許容する予定。

コーディング(プログラミング)向け 欧文モノスペースフォント特集!!

改定を重ねて大ボリュームになってしまったので独立!

欧文モノスペースフォント + 和文デュアルスペースフォント ってどうなの?

百聞は一見に如かず、とりあえず見てみよう。

結論としては、「違いがある分、コメントや文字リテラルとの区別がつきやすくなって却ってみやすい」というのが私の意見。

レンダリングがよく、ウェブのように複数のフォントを順に指定できるVSCodeでやっている。

Input Mono > モトヤLマルベリ等幅 > MMCedar

Input Mono + マルベリ

私が普段VSCodeで使っている組み合わせ。

日本語の中に混じっていても読みやすい。割と統一感がある。

Fira Code > Migu 1M

Fira Code + Migu (in text)

Fira Codeもお気に入りのひとつ。

Fira CodeがどちらかというとSerifチックなので、Migu 1Mとはあんまり合っていないかもしれない。 だが、これがコードの中に入ると、どうだ。

Fira Code + Migu (in code)

違和感ないと思う。

Nova Mono > モトヤLマルベリ等幅 > Migu 1M

Nova Mono + マルベリ (in text)

Nova Mono はかなり癖のあるフォントだけれど、意外と日本語とまじってしまうと気にならない。 丸ゴシックのほうがいいというのはあるけど、丸ゴシックならだいたいいい感じだ。

Nova Mono + マルベリ (in code)

半々くらいにまじっているこのコードだとむしろ見やすい。

monofur > VLゴシック

monofur + VL (in text)

形状が独特なだけでなくグリフサイズが異なるmonofur。

違いがくっきりな分、かえって見やすい。

monofur + VL (in code)

agave > Migu 1M

agave + Migu

私がメールのサマリー部分で使っている組み合わせ(本文はInput Monoの組み合わせ)。

「違うと却って読みやすい」というのが伝わるのではないだろうか。

おすすめの欧文モノスペース(コーディング)フォント

日本語を交ぜ書きするため、一般的には日本で欧文モノスペースフォントが紹介される機会は少ないし、紹介されるとしてもだいたい定番のものになる (Source Code Pro, Anonymous Pro, Menlo, DejaVu Sans, Inconsolata, Droid Sans Mono, Ubuntu Mono あたり)。

そこで今回合成前提に欧文モノスペースフォントを探し回ったので、よさげなのを紹介しよう。

なお、日本語フォントだと

  • Migu 1M / VLGothic (アルファベットは同じ)
  • Migu 2M
  • MigMix

あたりが定番で、コーディングに適した欧文フォントと合成したものとしては

  • Osaka等幅 (Monaco)
  • Ricty / Myrica / Myricam (Inconsolata)
  • Source Han Code JP (Source Code Pro)
  • 更紗ゴシック (Iosevka)
  • Cica (Ubuntu Mono)

がある。

更紗ゴシックは中国語フォントだが、Jという日本語フォントファミリーを持っているので使いやすい。

monofur

monofur

まるっこくて可愛らしいフォントだけど、見やすく疲れにくい実用的なコーディングフォント。 識別性も大変高い。

ややコミックフォントっぽいけれど、実際はコードがびっしりでもかなり見やすい。

mononoki

mononoki

デフォルメ強くてシンプル。Ubuntu Monoなんかに近いフォント。

Ubuntu Monoほど文字密度がないので、記述量が多くても黒黒としなくて楽。 Ubuntu Monoほど特殊でもないし、より見やすいと思う。

やや幅なあるボクシーなスペースを持っている。

Agave

agave

monofurに近いまるっこい系。 もっとデフォルメが強くて非常に実用的。

似たグリフを持っている文字が全く違う形状になっているので識別は非常にしやすい。 グリフは小さめで、スペースの節約にもなる。

スペースの比率は昔ながらのターミナルフォント的。

印刷するときにも好まれる感じのフォントだと思う。

Monoid

Monoid

今風ターミナルフォント。

線が少なくシンプルだけど先別しやすい。

そして、めちゃめちゃキレイ。Retinaというスタイルがあるくらいだから自信あるんだろう。 すっきり見やすい。

フォントは縦長でグリフが大きめ。 ->, >=, !=, */ といった文字列が特殊な表示になる。

私のmonospaceはMonoid+Migu 1Mになっている。

Hermit

Hermit

ちょっとくどいけど、すごくかわいくて見やすい。

古のIBM系ターミナルフォントを今風にしたみたいな感じだ。 よく見るとブサイクなのだけれど、なかなかかわいらしい。

Atomで使うと細いウェイトが優先される。

Input Mono

Input Mono (Default Setting)

非常に人気の高いらしいフォント。

実際、きれいでかなり見やすい。 テイストとしては Source Code Pro に近い。わずかにタイプライター調。

密度あげたい人はCompressedというバージョンもある。 私はコーディングフォントは四角いスペースのほうが好きだけど、縦長が好きな人にはお勧め。 そこまでいかないCondensedやNarrowもある。

また、好みの分かれるグリフ(i, l, {}, *, a, g)についてはダウンロード時に調整可能。

Luculent

Luculent

lの見やすいフォント。

グリフはちょっと縦長だけど、左右に少しスペースがあるので割とみやすい。 縦長ウィンドウには割と合う。

Boldがわかりやすいのも特徴的。

Monofonto

Monofonto

あまり変哲のなさそうなコンソール系フォントだけど、グリフが小さくて見やすいので、ディスプレイの解像度が低かったりすると結構便利だと思う。

1366×768で作業している人はとりあえず入れておくといいかも。

昔からある、コーディングフォントとしてはお手本のような形状。

Sudo

Sudo

Monofontoよりさらに小さくてみやすいミニマル向けターミナルフォント。

小さいのもあるが、どちらかといえば縦長で横のスペースが少なくて済む。 逆に縦に関しては行間広めなので意外と節約できない。

フォントサイズが小さくなっても読みやすい。

Envy Code R

Envy Code R

丸みを帯びて読みやすいターミナルフォント。

シンプルながらグリフの識別も楽で、連続するシンボルも見やすい。 シンボルは合成するというアプローチもあるが、こちらは逆に明確に分割する。

アプローチとしてはUbuntu Monoに近いが、もっとオーソドックスな形。

Fantasque Sans Mono

Fantasque

カーブがかってちょっとおしゃれなフォント。コード密度が高いときにはそれほど読みやすくないけど、識別はしやすい。

ちょっとタイプライターフォントと草書体フォントを混ぜたような感じ。 小文字のベースラインがちゃんと揃ってないのもおしゃれなんだろうか。

l, 1, Iの識別性は大変よい。その他見分けやすく読みやすい。 タイプライター系フォントが好きな人には結構いいかも。

CPMono

CPMono

グリフサイズがboxyなフォント。 おしゃれなterm系フォントといった趣。 ちょっとごついけど、結構見やすい。

欠点として、()[]が識別しにくい。あと、1lもだいぶ識別しづらい。 実用よりはややおしゃれよりのフォント。

Fira Code

Fira Code

Source Code Proと同じようなオーソドックスなフォント。 見間違いやすい文字の識別性が非常に良いよう設計されているほか、->, =>, >=, */, == != && といった文字列の結合・特殊化も行う。

すごく今風なコーディングフォントという感じで、欧文圏ではかなり人気もあるらしい。

NovaMono

NovaMono

シンプルな形状でまるっこいフォント。全体的に丸いので読みやすくはないが識別性は高い。

「識別しやすいおしゃれフォント」としても使える。密度の高いコードに使うとなかなか読みづらい。

OCRA / OCRB

OCRA

OCRB

OCRフォントは決まりきった形状。 特殊なフォントでコーディングに使うことは稀だが、OCRBはなかなか使いやすい。

Cousine

Cousine

非常にオーソドックスでみやすいモノサンズ。

Droid Sans MonoやDejaVu Sans Monoと引き換えにできるかも。

Crisp

Crisp

レトロビットマップ調。

Iosevka (更紗ゴシック)

Iosevka

変形するシンプルなターミナルフォント。

あまり使われないけれども、更紗ゴシックでも使われている。

Iosevka Term

Iosevka Term

変形しないIosevka。Fira Mono, Menlo, Pragmata Proなどさまざまな形状のものがあり、これはMonaco形状。

NK57 Monospace

NK57

レトロなターミナルフォント。

幅広でボクシーだが、幅は色々あり、 Cd(Condensed), Sc(Super Condensed)、さらに逆に幅広な Ex(Extended), Se(Super Extended)が揃う。

Space Mono

Space Mono

ちょっと誇張した形状のターミナルフォント。

Telegrama

Telegrama

レトロ調ターミナルフォント。

ビットマップ風のRawとスムーズなアウトライン調のRenderの2スタイルがあるが、スタイル指定できない場合はRawが選択されてしまうため、 Rawはインストールしないのも手。

TerminessTTF Nerd Font

TerminessTTF Nerd Font

Terminusに大量のシンボルフォントを含むNerd Fontのパッチをあてたもの。

Terminusはビットマップフォントだけど、こちらはスムーズなアウトラインフォントとして扱える。

Camingo Code

Camingo Code

オーソドックスなターミナルフォントだけれど、これ系としてはシンボルフォントが少し特徴的。

ターミナルフォントは似通ってるのが多いので、説明書きが大変。

Espresso Mono

Espresso Mono

キレイなターミナルフォント。 アンダーバーがややみづらい。

昔はよく見たけれど、最近はちょっと入手困難。

Andale Mono

Andale Mono

シンプルで余白大きめのターミナルフォント。

シンボルが見やすくて結構実用的。

SF Mono

SF Mono

AppleデフォルトのSan Franciscoフォント…らしい。

お手本のようなターミナルフォント。 @の造形がちょっと微妙なのが残念ポイント

IBM Plex Mono

IBM Plex Mono

IBMで今なお使われているコンソールフォント。

Go Mono

Go Mono

セリフ系のものスペースフォント。

セリフ系としては割とみやすい。

Overpass Mono

空間ひろめでみやすいターミナルフォント。

Nouveau IBM Mono

Nouveau IBM

私にとってはすごーく懐かしいIBMのコンソールフォント風。

DEC Terminal Modern

DEC Terminal Modern

Unixのレトロななにかでよく見かけるDECのコンソールフォント風。

意外とみやすい。

IBM 3270 Font

IBM 3270

Nouveau IBMよりさらにレトロなIBMフォント。

Cutive Mono

Cutive Mono

線の細いセリフ系モノスペースフォント。

おまけ。定番モノスペースフォント

Source Code Pro ( Source Han Code JP / Merica / Mericam ) / Noto Mono

Source Code Pro

Adobe と Google の共同開発フォント。 フリーフォントの品質の革命とも言えるもので、非常に良い。

グリフは割と幅があるのだが、スペースは行間が大きいため縦長。 表示スペースを多く取ることに好みが分かれる。

非常に見やすくモノスペースフォントの優等生。

DejaVu Sans Mono

DejaVu Sans Mono

Bitstream VesaのUnicode版として2004年から開発されている老舗フォント。 モノスペースフォントも歴史は長い。

グリフが揃っていることを重視したフォントプロジェクトなので見た目に美しくはないが、実用性はMonacoに負けず劣らず高い。

Droid Sans Mono

Droid Sans Mono

ハンドヘルドデバイスなどでの利用を想定し、アセンダーコーポレーションが開発するフォントファミリーのDroid。

その中のモノスペースフォントとしてDroid Sans Monoがある。

Android端末上で等幅フォントを表示する機会は少ないのだが、実は欧文圏では割と人気がある。 日本で人気がないのは、多分Droid Sans Japaneseの品質がだいぶひどいことにあるだろう。

オーソドックスだが、0とOの識別性が低いのが難点。

Inconsolata (Ricty)

Inconsolata

日本人でもある程度使っている人はいる、Rictyに含まれているので実はかなりいる細くて縦長のものスペースフォント。

飾り気はなく、美しくもないが、シンプルで見やすい。 また、特殊スペースが小さくても文字が小さくても読みやすい。

Ubuntu Mono (Cica)

Ubuntu Mono

本家は別にかわいい路線じゃないのに、なぜかかわいいフォントで人気になってしまったUbuntuフォントファミリー。

Ubuntu MonoもちょっとかわいいフォントとしてSource Code Pro, DejaVu Sans Monoあたりと並んで割と席巻している。

日本でもユーザーは多く、最近はCicaという合成フォントも登場している。

Anonymous Pro

Anonymous Pro

細めのモノスペースフォントで、ややタイプライター風。

ブック向きで印刷映えする。

Iとlがやや判別しにくい。 広い画面で使うにはあまり向いていないフォントでもある。

Hack

Hack

Anonymous Proと並んで「欧文モノスペース」として紹介される定番フォント。

細めのタイプライター風のAnonymous Proに対してこちらは太めのターミナルフォントになっている。 ターミナルフォントとしてはオーソドックスな形状。識別性はかなり良い。

Meslo (Menlo)

Meslo

Mac OS Xのモノスペースフォントは10.6からついにMenloになった。

というわけで負けじとBitstream Vera Sans MonoをMenlo風のフォントに仕立てたのがMeslo。

本当にMacは世界的にファンが多い。

フォント自体はHackと非常によく似たターミナルフォント。 Monacoほどの識別性がないため、だいぶ地味になった。

Monaco

Monaco

Apple製のフォントはプロプライエタリだが、GitHubにクローンプロジェクトがある。

コンパクトで縦長のグリフを持つ。長くMac開発環境の定番として君臨しているだけあって非常に見やすい。非常にオーソドックスで望ましい形をしている。 book系のものスペースフォント。

Roboto Mono

Roboto Mono

非常にオーソドックスなターミナルフォント。 シンプルなだけにみやすい。

monospace fontを指定した話

Mimir YokohamaのCSSでmonospaceをより積極的に指定するようになった。

Mimir Yokohamaにはプログラミング関連の記事があるが、基本的には初心者向けである。

そのため、ユーザーはプログラミング向けのフォントを持っていない可能性もある。 また、そうでなくてもブラウザのmonospaceフォントをプログラミング向けのフォントに設定している可能性は低い。

日本語OSの場合、Windowsではデフォルトに“MS ゴシック”、Macでは“平成角ゴシック”が使用される。 これらはいずれもコードの表示には全く適さない。

英語環境の場合はWindowsは“Courier”, Macは“Courier New”が使われるようだ。適しているとはいえないが、いくらかマシである。

だが、現在の環境では1それぞれコーディング向けのフォント、Windowsなら “Consolas” が、Macなら “Menlo” が導入されている。 なので、次のようにすれば話は解決する。

Linuxのことも考えなくてはいけない。 Linuxの場合はコーディングに適したフォントが豊富なので心配する必要はないのだが、日本語環境だとmonospaceが “IPA ゴシック” だったりするかもしれない。 と、なるとこうなる。

だが、私は無意味なシステムデフォルトフォントの強制などしない。 ユーザーがわざわざ(おそらくは好みによって)インストールしているものは尊重されるべきだ。

そこで、「わざわざインストールした可能性の高いものを優先する」というポリシーで追記した。

ただし、グリフ変形のあるフォント、モノスペースではあるがコードとしての読みやすさに欠けるフォントは除外した。 これは、コードに慣れていない初心者に無用な混乱をもたらさないためだ。

一方、初心者が学びに使用する上で望ましいフォントとしてInputを挙げている。 そのためにインストールガイドまで容易するほどだ。

Inputを配布しないのはInputがライセンス上それを許していないためである。

また、Webフォントとして利用することもInputは許可していないが、それを別としても(和文フォントのように重いわけではないが)表示に必須ではないにもかかわらずそれなりにサイズのあるフォントをダウンロードさせることは全く好ましくないため、Inputに限らずWebフォントを使うのではなく、できるだけコーディングに適したフォントで表示させる、という方法を取っている。

また、Sans-serifやSerifと違って意図したように表示されない場合の問題が大きいため、かなり記述量が網羅的に多くなっている2

なお、monospaceフォントの記述を行ったのは、これからプログラミング関連の記事を更新するための布石でもある。

実はChiemoniでも同様の問題を考慮して同様の記述を加えている。


  1. Macがコーディング向けの“Monaco”を採用したのはとても昔の話なので案ずることはない。Windowsの場合、Windows Vista以降は“Consolas”が導入されている。

  2. Serifフォントは「明朝体ならなんでもいい」に近い感覚なので別に細かく記述する必要もないが、Sans-serifは「丸ゴシックで表示したい」ということであり、丸ゴシックは比較的少ないので網羅的に記述することもできなくはない。 だが、丸ゴシックでなければ困るわけでもないので網羅的な記述にはなっていない。

事業をすることについて、Mimir Yokohamaについて。

これを書くことにした理由

起業に関する記事は、時折見ることがある。

商工会にいるときは割と見る機会も多かったし、Twitterでちらほら流れてくることもある。 私自身、起業を勧めることもないではない。

でも、あまり起業に関する文章を見るのは好きではない。

多くは考え方が甘ったるく、また自己陶酔的だからだ。

だから、ちゃんと何を考え、どうするべきなのか、現実はどうなのか、という話をしよう、と思った。

Mimir Yokohamaのページでする話でもないし、多分Journalでする話でもないから、ここでするのが適当だろう。 私のことで聞きたがる人がいるとしたら、単なる経営者としてではなく1、技術者としてだろうから。

別に経営者は「えらく」はない

“労働者 < 経営者”の図式を持って、起業すると人より上にたったような気になる人が結構いるのだが、そんなことは全くない。

言ってみれば、優秀な労働者とは金将・銀将であり、独立して経営者になる、とは歩兵になるようなものである。 そこからと金になれるかどうかは、その後の話であって、起業しただけではグレードダウンしているのだ。 さらにいえば、普通は起業することで収入もグレードダウンする。

音楽家とか、作家とか、漫画家とか、アイドルとか、ポピュラリティのある人がもてはやされ、その発言が金言であるように扱われることも多いけれど、 そんなことは全くなくて、その専門的スキルの外においては特段の価値があると保証されるわけではない。

別にすごくかわいいアイドルや大人気YouTuberが言うことならなんでも正しいわけでもない。

経営者が言うことも、労働者が言うことよりも正しいわけでもない。

典型的経営者の話

結構、「おもしろそうだからやる」「お金が欲しいからやる」「モテそうだからやる」みたいな人が多い。

基本的にその発言傾向はニートと似ている。

ただ、違いがあるとすれば、お金に対する執着であり、商才に関するものだ。

基本的に経営者でうまくいく可能性が高いのは商人である。 お金に執着し、お金のために自己と他者をどれだけ犠牲にできるか、というところが問われる。 また、お金の臭いに敏感で、すぐにキャッチできることもだ。

商才がある人は儲けていくし、なければ「飽きたからやめる」「儲からないからやめる」「つまんないからやめる」「大変だからやめる」みたいなことになる。 実際そんなケースがとても多い。

そして、これには中身がないのだ。

なにをしたいか、というのが自分がどうなりたいか、ということであって、 直接的な関わりの中で何をなしたいか、というのがない。 社会にどうしたい、ということしか出てこないのもそうだ。

直接的なアクションが何を目的としているのか、というのが直接的な受益者をどう変えるのか、という話がなかなか出てこない。

私は「技術なんて求められてない」「技術なんて必要とない」と言った経営者のことを忘れていないし、許す気もない。

経営の現実

冒険したくないなら、特別な意思がないなら経営なんかしないほうがいい。

まず働いたらお金がもらえる、という前提がなくなる。 何百時間働いて数百円の売上、収支は赤字とか普通にある。

労働時間で守ってもらえることもないし、社会保障もなくなるし、 社会的にもより厳しい条件になる。

したいことができる、と思うかもしれないけれど、どちらかといえばしなければならないことが圧倒的に増えるのでできることは限られる。 内容は自由になるけれど、「したいことをして過ごす」わけにはいかない。やらなければならないことにしたくないことがどうしたって大量に紛れ込むからだ。

志高い人は、技術や実、人のためになることがお金につながるわけでもないということも心しておかないといけない。 もちろん、それは飯の種にはなるのだけど、そんなことより詐術のほうが余程お金に変わる。

それでも経営する理由

私だって経営がしたいわけではないのだけど、自分の望むことを叶える方法が唯一経営だったということでしかない。

経営をすることは、 社会の既存の枠組みやルールから逸脱できる ということだったりする。 自分のしたいことが今の社会で実現する方法がないのなら経営してしまえばそこから外れた枠組みを自作することができる。

パソコンを自作するのは面倒だ。ありものを買ったほうがいい。 けれど、パソコンを自作すれば既成品とは異なるものが作れる。

自動車を自作するなんてもっと大変だ。 でも自作された自動車はメーカーが絶対に作らないようなものだって可能だ。

経営するということは、働くということを自作するということだ。

成功は保証されていない。報われるとは限らない。 だから報われるために努力するのであって、そこまでして為したいことがあればこそ、なのだ。

私は、IT企業の構造が嫌だった。 いつの間にそんなにつまらなくなったのだろう、創造性はどこにいったのだろう、ガチガチに縛ることばかり好きな人だけになってしまったのだろうか、そんなことを思った。

技術のない人の欺瞞が嫌だった。 無知につけ込んで実に関係なくお金をとり、売れれば騙そうが構わないと考える。 さらに無責任のおまけまでついてくる。

コンピュータのことを嫌い、怖がる人々が辛かった。 この面白さが伝わらないのが悲しかった。

そして、私自身にしたって、「変わっている」ことを理由に否定されるだけなのも辛かった。

なら、私が持ちうるものを、人々を幸せにするために使いたかった。

別にそのほうが儲かるとは考えていなかった。というよりも、技術力だけで叩いていけばお金はとれるという確信があったので、お金に関しては大幅に妥協することを覚悟していた。

何度か言っているけれど、自営業になったこと、Mimir Yokohamaをおこしたそもそもの理由はそんな志の高いものでもなくて、 もともとは音楽市場縮小で食べていけなくなったからだし、恋人ができたときに仕事の間は別々というのが嫌だからだった。

でも、なにをするかはそれでは決まらない。 なにをするかは、祈りに近い気持ちを込めていた。

中身のある経営というのは、少なからず今の社会に対する不満があって、その社会の中でなにかを実現したい、なにかを変えたいと思うからこそのものだと思う。

だから、なにが流行りそうだ、今のトレンドはどうだ、何が儲かりそうだということでビジネスをはじめることには私はどうしたって眉をしかめる。 あなたの志は?と思ってしまう。

起業するんだったら

もし、あなたが今の社会に不満を持っていて、 それに対して具体的なビジョンがあって、 そのビジョンが誰かによって変革されることではなく自分が具体的な実現の手段を持っているのならばやったらいい。

あるいはあなたが冒険者であり、かつ優れた業師であり、だれもそれを使いこなせる経営者がおらず、 かつ経営などという余事に力を割いたとしてもそのほうが多くを発揮できるのであればやったらいい。

別にそれが偉いわけでも、人の上に立てるわけでも、自分がすごくなれるわけでもないし、 お金持ちになれるわけでもモテるわけでもないけれど、 やり場のない気持ちを押し殺しているくらいならやればいい。

そうでないなら誰かを犠牲にして悦にひたることになるだけだからやめておいてほしい。 もっとも、そんな人は止めたところで聞きはしないのだけれど。

せっかくだから、人に喜ばれて、人を幸せにする仕事をしようじゃないか。


  1. そういうのはすごく儲かってる人に聞くと思う。

フォント帳アプリを作る → Linuxフォントの闇に触れる

追記分について

日本ではあまりなじみのない欧文コーディングフォント(プログラミング向けフォント, モノスペースフォント)をなんでこんな苦労してるんだろうとか思うくらいの労力を掛けてカタログ作ったので、気合いれて紹介させていただく

ぜひ見ていただきたい。

はじまりはmonospace

フォント一覧として“monospaceフォントの一覧を作りたい”と考えたのだ。

アプリ自体は全フォント一覧も作れるようにしたが、monospace限定でも出力したい。 どのような方法があるかと考えた。

調べるとspacingの値を見ればわかるということはわかったのだが、spacingMonospaceProportionalのような文字列ではなく、90, 100といった値になっている。

とりあえず90100もおおよそmonospaceだということはわかったが、90を提示するがmonospaceでないフォントもある。

だいたい90100の違いはなんなのか…もしかしてQtのmonospaceフォント一覧に関係があるのか…

と調べていくといろいろわかってきた。

100FC_MONOの定数であり、Monospaceのことであるらしい。 90FC_DUALであり、幅を2種類持っているもののようだ。

確かに等幅和文フォントは “monospace” ではない。 “dualspace” である。

では等幅和文フォントのspacing100にした場合Qtウィジットもmonospaceとして認識してくれるのだろうか?

FontConfigの一覧はいじれない?

で、どうやらfontconfigの設定(fonts.conf)はフォントを “要求されたとき” には反映されるけれど、 “リストするとき” には無視されるようだ。

例えばこんな設定ファイルを作る。

Migu 1Mのspacing100(FC_MONO)になる。

% fc-match "Migu 1M" : spacing family
Migu 1M:spacing=100

けど、リストには入らない。

% fc-list :spacing=100 : family | grep -i migu

Foogothicもちゃんと認識はされているけど

% fc-match -a Foogothic : family | head
Anonymous Pro
Anonymous Pro
Anonymous Pro
Anonymous Pro
Migu 1M
Migu 1M
Bitstream Vera Sans
Bitstream Vera Sans
Bitstream Vera Sans
Bitstream Vera Sans

リストにはない。

% fc-list | grep -i foo

90(FC_DUAL)100(FC_MONO)として認識させると、フォントに設定されている幅を無視するアプリケーションが存在するため、リストに入れてくれるわけでもないのならばデメリットしかない。

欧文フォントを和文で使いたいという場合には和文フォントを加える形にしてあげれば良いのだが

問題はQtである。

QtはMonospaceフォントとしてFC_MONOの値よりもspacingが大きいフォントを提示する。

問題は、FC_MONO100であり、FC_DUAL90であるため、FC_DUALなフォントは提示されない、ということだ。

この問題はバグとして報告されているのだが、今以て解決していない。

現状、monospaceを和文フォントにするか、適当な(使わない)欧文monospaceフォントをインストールして、その名前を利用して置き換えるくらいしかなさそうだ。

和文プロポーショナルフォントの話

実は和文フォントは一般的には「ラテン文字はプロポーショナル、全角文字は等幅」となっており、 日本語部分までプロポーショナルになっている「和文プロポーショナルフォント」というのはかなり珍しい。

このためか、ラテン部分がプロポーショナルであるにもかかわらず、spacing=90にしてしまうフォントが結構あるようだ。例えばDynafontとか。

なので、今回のスクリプトは-s 90とすればdualspaceフォントを含めてリストしてくれるけれども、必ずしも等幅フォントであるとは限らない。

今回のスクリプト

GitHubにアップした。

基本的にはFontConfigから値をひらってeRubyで埋め込んだHTMLを作るプログラムである。

プログラム自体は至ってシンプルなものだ。 どちらかといえばFontConfigに関する知識のほうが求められる。

READMEにある通り、うまく動作しない部分がある。 family名を指定しても正しく表示されないもの、fullnameがBoldなどになっているもの、 spacing=90といいながら等幅フォントではないもの1kanahaniが実態と合っていないもの、 などなど「フォントの情報って結構ガバガバだなぁ」と感じてしまう。 もちろん、フォントの情報から取っているわけで、がフォントにウソ情報を書かれたりするとスクリプト側では処理しがたい。

ウェイトの違うフォントが別ファイルになっているものと同一ファイルのもの、PlainやNormalなどRegularではない標準フォントウェイト名であるためにBoldが標準になってしまうもの、 ビットマップとスケーラブルがスタイルの違いになっているもの(例えばTelegramaはRawがビットマップ、Renderがスケーラブル)と厄介なものは色々ある。

欧文モノスペースフォント紹介

ボリュームがすごーく増えてしまったので独立させました

今回の件で気づいたこと

欧文フォントフェイスはかなり似ている

「読みやすいアルファベット」という条件がついていて、あまり標準的でない形は読みづらさにつながる。

結局、こうした条件のためにだいたいのフォントが似ていて、「ターミナル」「タイプライター」「セリフ」「サンセリフ」の4種類で分類できるような形状しか生まれてこない。

だが、微妙な違いが読みやすさにつながる部分もある。 現在人気のフォントはどれも似たようなサンセリフまたはターミナル体なのだけど、探せばちょっと変わったフォントもあるにはある。 人気のあるフォントの中ではMonacoやUbuntu Monoがちょっと変わったグリフをしている。逆にHackやDroid Sans Monoはものすごく普通。

商用フォントはいいぞ

Dark Mono, Operator, Native, Range Mono, Vivala Codeなど見比べて「おっ、いいな」と思うフォントは軒並み商用フォントになっている。

ただし、プログラマ、コーダーなど「日がな一日プログラムを書いている」人に関しては、これぞと気に入ったフォントがあれば買ってみるのも手ではないだろうか。 一日中向き合っているものだし。

欧文フォントも売られているものは高いものもある

Operatorなんて$199もする。 1書体のお値段としてはモリサワフォント並。 Pragmata Proもデスクトップ用 * レギュラー/ボールド/イタリックで€199

日本語フォントとは制作労力が雲泥の差なので、ちょっとえげつない値段だと言っていい。

Dark Monoも40ポンドとかなりお高め。

Atomはレンダリングが汚い

フォントのウェイトやサイズがばらつきやすく、autohintのようなガタツキも発生する。

うまく表示してくれるフォントを探すのにはずいぶん苦労した。

Atomでキレイに表示してくれるのはCPMonoなのだけど、CPMonoはコーディングフォントとして決して快適ではない。

日本語と混ぜるなら、agave, Fantasque, Fira Code, Luculent, Mesloあたりが快適。 私は結局Fira Code+Migu 1Mにした。

この組み合わせは非常に違和感がないが、後述のようにもう少し違和感があったほうが読みやすい。 その点、LuculentやMesloのほうが有力だった。

フォントの情報はいい加減

「漢字グリフはなくてひらがなだけなんだけど、haniは書いてあってkanaは書いてない」みたいなフォントもある。

商用フォントでも結構ザルである。 プログラムとしてはフォントの情報に基づいて処理するしかないわけで、「なんでここでそのフォントが?」と思うようなフォントが提示されたり、偽薬に提示されなかったりというのはここらへんに理由があるのだろう。

日本では紹介されていないモノスペースフォントはいろいろ

日本人としては日本語Glyphのないフォントは使えない、という感覚があるのだろう。 あまり紹介されることもない。

だが、実際にはプログラム中には日本語なんてほぼ使わないわけで、モノスペースフォントは日本語Glyphがなくてもあまり困らないし、 今はglyphがなければそれなりに処理してくれるのが普通なので別に好きに組み合わせても良いのではないだろうか。

日本で紹介されるものは人気があるというよりも無難なものが多く、実際にはもっと使ってみる価値のあるフォントは色々ある。

フォントレンダリングの微妙な差

KDEアプリケーションは割とにじみ強く太めに描画するため、キレイに見える。

Gnomeアプリケーションはもっとくっきり描画する。

どちらもFontConfigを使っているのだけど、描画ライブラリの微妙な差なのか、見え方が割と違う。 FirefoxとChromiumの描画差は気づきやすい。

そして前述のようにAtomはあまりよくない。

autohinterは諸悪の根源

以前は有効にするのが一般的だったように思うautohinterだけども、有効にするとガタガタになる。

フォントが寄る、ガタつく、崩れるなどのことがあったらautohinterを切るといいかも。

FontConfigはデフォルト設定がだいたいいい感じ

FontConfigの設定はディストリビューションによって作り込まれていることが多く、違いがあるけれども、 Arch設定だと色々いじってみても基本的にはデフォルトが良いようだ。

nobitmapと、サブピクセルレンダリングの配置くいらはいじったほうがいいけども。

日本語とアルファベットは差があるほうが見やすい

コーディング向きのglyphを持つ日本語フォント2の場合、統一感があるように調整されている。 「日本語とアルファベットの統一的デザインってなんだ」と思うかもしれないが、主にはグリフのボックスサイズと、線の太さである。

普通は「半角は全角の半分」となるように設計する。Source Code JPフォントの場合は全角は半角の1.5倍幅になっている。

だが、Linux環境ではこのような和文フォントのスペーシングがうまく適用されないことが多い。 Atomの場合和文フォントを指定すると縦には揃ってくれない。このことから、このようにメリットは少ない。

また、日本語にアルファベットを混ぜ書きするケース(スペースを持たないケース)においては、アルファベットは「検索(eyeboll-search)の対象」であることがあり、 区別しやすいほうが良いと考えられる。

このことを踏まえると、「日本語とアルファベットの統一感はなくても困らないし、むしろないほうが便利」だったりする。

おまけ: 今回のフォント画像に使ったコード

JavaScript組み込みHTMLのPandocテンプレートである。

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="$lang$" xml:lang="$lang$"$if(dir)$ dir="$dir$"$endif$>
<head>
  <meta charset="utf-8" />
  <meta name="generator" content="pandoc" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=yes" />
$for(author-meta)$
  <meta name="author" content="$author-meta$" />
$endfor$
$if(date-meta)$
  <meta name="dcterms.date" content="$date-meta$" />
$endif$
$if(keywords)$
  <meta name="keywords" content="$for(keywords)$$keywords$$sep$, $endfor$" />
$endif$
  <title>$if(title-prefix)$$title-prefix$ – $endif$$pagetitle$</title>
  <style type="text/css">
      code{white-space: pre-wrap;}
      span.smallcaps{font-variant: small-caps;}
      span.underline{text-decoration: underline;}
      div.column{display: inline-block; vertical-align: top; width: 50%;}
      body { padding: 50px; font-size: 25pt; }
$if(quotes)$
      q { quotes: "“" "”" "‘" "’"; }
$endif$
  </style>
$if(highlighting-css)$
  <style type="text/css">
$highlighting-css$
  </style>
$endif$
$for(css)$
  <link rel="stylesheet" href="$css$" />
$endfor$
$if(math)$
  $math$
$endif$
$for(header-includes)$
  $header-includes$
$endfor$
</head>
<body>

$for(include-before)$
$include-before$
$endfor$
$if(title)$
<header>
<h1 class="title">$title$</h1>
$if(subtitle)$
<p class="subtitle">$subtitle$</p>
$endif$
$for(author)$
<p class="author">$author$</p>
$endfor$
$if(date)$
<p class="date">$date$</p>
$endif$
<input type="text" size="20" id="FontForm" /><input type="button" value="Change" id="FS" />
</header>
$endif$
$if(toc)$
<nav id="$idprefix$TOC">
$table-of-contents$
</nav>
$endif$
<input type="text" size="40" id="FontName" style="border: none 0px; font-size: 26pt; background-color: #fff; padding: 5px; border: #39f double 3px; color: #333; margin-top: 2em; margin-bottom: 0.8em" />
$body$
$for(include-after)$
$include-after$
$endfor$
<script type="application/javascript">
  var fm = document.getElementById("FontForm")
  var nameBox = document.getElementById("FontName")
  document.getElementById("FS").addEventListener("click", function(e) {
    for (var code of document.getElementsByTagName("code")) {
      code.style.fontFamily = fm.value
      nameBox.value = fm.value
      nameBox.style.fontFamily = fm.value
    }
  }, false)
</script>
</body>
</html>

  1. Iosevkaはdualspace扱いになっている。

  2. そもそも合成でないフォントでそのようなフォントはかなり少ない。M+(VLゴシックとMiguもこのglyph)くらいではないだろうか。Source Han Code JPとOsaka等幅は専用に調整されてリリースされているものなので含めてもいいかもしれないが。

KDE Plasma5 * Conky

KDE Plasma5の場合、Conkyはwindow_typeによって

  • 表示領域をConkyに奪われる(ウィンドウが置けなくなる)
  • デスクトップをクリックすると裏に行く
  • 通常のウィンドウとして表示される

といった問題が発生する。 これらの問題は他のデスクトップよりシビアだ。

次のようにすることで、正常に表示・動作し、透過も機能する。

own_window = true,
own_window_transparent = true,
own_window_class = conky,
own_window_type = override,
own_window_hints = "undecorated,below,skip_taskbar,skip_pager",
own_window_argv_visual = true,
own_window_argv_value = 0,

新しい設定ファイルではyes, no ではなく、 true, false であることに注意してほしい。

KDE Plasmaとしてはウィンドウとして表示される形式が望ましいもので、own_window_hintsによって表示方法を制御する。

富士通の「はじめてのじぶんPC」、何が問題か

富士通から子供向けのラップトップ「はじめてのじぶんPC」が登場し、これがプチ炎上している。

しかし詳しくない人から見れば何が問題なのかわからないだろう。 だが、ここは変なカモを増やしてしまわないためにも、(パソコン選択に関する記事も遅れているので)解説しておこうと思う。

CPUの問題

CPUはCeleron 385Uである。

処理性能は極めて低い。 一体なにに使うのだろう。ウェブブラウジングですよ、という話だとしたらなかなかセンシティブな問題で、なんといってもフィルタリングだなんだと言っているくらいなのにブラウジング専用パソコンを与えるのか、そもそもそれならスマホでいいじゃないか、といろいろ問題である。

というか、ウェブブラウジングとかそういう軽い作業だけなら親のコンピュータを借りてもいいわけだし、一日中ウェブブラウジングする前提ならそれはそれで問題だろうし、一体なにに使いたいのかがわからない。

基本的にCeleronは「世代をこえてしょぼい」上に385Uなんていうともう買ったときからおんぼろたんのほうが遥かにマシというところからスタートすることになる。

メモリの問題

4GB。なにをするにも足りない4GB。 Windows10は稼働中にもりもりメモリを使っていく傾向があるので(起動時に足りていても結局足りない)、4GBでは何もしなくても足りない、が正しいかもしれない。

オフィスソフトを使うのは苦痛でしかないだろうし、私だってメモリが4GBならそれならに特殊な運用を考える。

「子供のうちからメリもは4GBで十分と教育するためではないか」(IT企業が劣悪な環境での開発を強いることに対する抵抗感を軽減するためではないか)というジョークがあったが、割と真実味があるレベルである。

理解している人の自己責任としての4GBならいいのだが、「わからない人向けに4GB」というのはどう考えても無知に付け込んでカモる気にしかみえない。

サイズはOK

14インチというサイズはちょっと微妙だ。 モバイルとしてはやや大きめ、家で使うには小さい。

そういう微妙なところをつきたいケースもあるし、私が使っているX1 Carbonは14インチでありながら13.3インチとしても軽い重量で見やすく大きな画面を兼ねるが、この場合そうではない。

何を狙っているのかよくわからないが、基本的にこれはよいとする見方が大部分。

重量はひどい

2kgという重量は14インチとしてはエントリーモデルの重量であり 持ち歩きの重量ではない

一般的に持ち歩き用のラップトップの重量は1.5kg以下。私のX1 Carbonは約1kgだし、軽いものでは800gを切るほどだ。

なのに2kg。ただえでさえ残酷といえるほどの重量になりやすい子供の荷物に2kg。

私だったら許せない。

以上を踏まえて

これだったらモバイルラップトップの中古のほうがマシではないか。

別に特別にタフ設計ということもないだろうし、不足することが明らかなのに、知識がないことを前提として使わせるというのが批判を浴びている部分だ。

ちなみに、7万円〜9万円強という値段からして全く安くもない。 やたら高い値段で半ばゴミのようなパソコンを売りさばく、という最悪のビジネスモデルだと言っていいだろう。

私は、こういう無知につけこむビジネスは、大嫌いだ。

Coinhive逮捕、軽く解説

はじめに

Coinhive設置で逮捕者が出たこと、そして取り調べその他の措置が不当なものである可能性が高いことから話題になっている。

これについてちょっと解説しておこう。

Coinhiveとは

JavaScript実装のマイニングツールである。

このマイニングは使用者の利益になるわけではなく設置者の利益になる。 webページに設置し、ユーザーがそのページを読み込む際に一緒にロードされ、ページを開いている間マイニングが実行される。 このマイニングで得た利益は配信者に還元される。

つまり、色合いとしては広告に近いが、ユーザーの目に入ったり、なんらかの購買行動を要求したりするわけではなく、ユーザーのコンピュータの計算資源をお金にするわけである。

問題点はある

第一に合意形成がされず、「ユーザーに気づかれないように行われる」ことである。

広告の表示は広告が表示されていることをユーザーが知覚できる。 ところが計算資源を使われていることはユーザーはなかなか気づかない。

第二に、計算資源は「ユーザーが使わされる」ということである。

計算資源の少ない環境ではあまり特別な感じはしない話になるのだが、計算資源が膨大な環境だと広告や一般的なJavaScriptの負荷というのは微々たるものである。 ところが、Coinhiveで使うことができる計算資源はその比ではないので、計算力にかかる費用も電気代もなかなかすごいことになる。 広告と比べてユーザーの実質的な負担がだいぶ大きい(場合によってはすごく大きい)のだ。

第三に不透明性である。

第一の点も含めてだが、このことを踏まえて海賊版サイトなどで使われる傾向がある。

ウィルスかどうかの点

まず前提としてだが、「計算資源を目的としたウィルス」というのは過去にも存在した。

というよりも、むしろ一時期に至ってはウィルスの主要な挙動であった。 金銭を直接的に要求するタイプはそれより新しい主流であり、トラップ的なものを除けばあまり金銭を要求するタイプのウィルスは多くはなかった1

そもそも、「ウィルス」という言葉を使うと、感染性とかややこしい問題が絡んでしまうので、マルウェアというくくりにしよう。

利用者の意図しない目的のために計算資源を使う、という行為は、マルウェアと区別することはできない。

なお、「マルウェアと区別できない」のと「マルウェアである」の間には大きな隔たりがある。注意してほしい。

「悪しきこと」と「犯罪として取り締まるべきもの」であることは違う

Coinhiveが好ましくない、利用者にとって嫌なものであることは間違いない。

というよりも、その考え方自体が悪しき側に寄っていると言っていいだろう。

だが、そんなものはたくさんある。 水素水や、必ず痩せるサプリなどの広告しているもの自体が不正なもの、コンピュータが不安定な状態にあるなどと脅すものなど色々だ。

こうした不正なものの中で、例えば「クリックすると登録しましたと表示され、お金を支払うように脅すもの」については現行法において明らかに犯罪である。 だが、どこまでもついてくる広告や、操作しようとすると操作しようとした部分に移動する広告などは、ユーザーは非常に不快だと感じているのが実際だが、いまのところ犯罪ではない。

犯罪であるかどうかは、法に照らして判断されるべきものであり、「気に入らないから」「怪しげだから」というのは理由にならない。

そして、Coinhiveが犯罪かどうかについては、「Coinhiveが犯罪たりえる特別な理由はない」のだ。

広告はよくてCoinhiveは駄目だという理由は、「広告はみんなよく知っているから」という有名無罪理論である。 新しいテクノロジーや手法であり、認知されていないことを理由に取り締まれるとしたら、従来なかった新しいものは全て犯罪であるということになる。 そして、それらが常に取り締まられるわけではない。 「警察に目をつけられたか、あるいは気に食わなかったものを逮捕する」という恣意的な運用を実現するものである。

そもそも、法律というのは恣意的に運用してはならないという前提がある。 「不正指令電磁的記録に関する罪」はそもそもそのような恣意的運用が極めて容易な内容であり、問題視されていたのだが、「そんなことはありえない」と強弁して通したものだ。

そして、それが実際にこのように恣意的に運用されたということは、「プログラムを書く、あるいはシステムに携わるあらゆる人を難癖つけて逮捕できる法律を作った」のであり、 実際にそのような運用を開始した、という問題である。

Coinhiveが好ましいわけではないし、私としても許しがたいものであるとは思うが、 それは「現行法で取り締まってよい」ことにはならないのだ。 それは、極めて恐ろしい社会である。


  1. ウィルスのタイプとしては、「驚かせるもの」「コンピュータに対して破壊的なもの」「コンピュータの計算力を利用するもの」「情報を送信するもの」「動作を代理させるもの」が多く、「侵入経路を作るもの」「金銭を要求するもの」は少数であった。

テキストをスクロール表示させる

プログラムについて

諸兄も一度はYouTubveで見たことがあるのではないだろうか。

文字がただ流れるだけの動画を。

自分のペースで読めない上に内容に乏しく、非常にイライラするものだが、 作業ウィンドウ以外で流しておくことでウィンドウフォーカスを切り替えなくて済む、というメリットもある。

特にmpvを使うと、右クリックで再生/停止ができるし、再生速度もコントロールできてまあまあ便利だ。

ただ、検索性がないのでやっぱりストレスである。

そこで、テキストリーダーに自動スクロール機能が欲しい、と思った。

ありそうだが、見当たらなかった。

もちろん、一行単位であればsleepreadでも組み合わせればいいのだが、これはパッと動いてしまうため目の追従が難しく、読みづらい。 1ピクセルずつ動かしたいのだ。

xdotoolを使う、という方法も考えたのだが、意図したようにはうまくいかなかった。

JavaScriptを使えばすごく簡単なのに…というわけで、JavaScriptを使う方向でがんばることにした。

すごーーーーく単純に一時ファイルでHTMLを作ってQtWebengineで表示すればいいと思って、Pythonで作ったのだが…

…Surfでよかった。

まぁ、配布するならSurfみたいなマイナーなものは入れたくないなんていう天邪鬼さん1や、Surfは入っていないなんていう弱小ディストリさんはいっぱいいると思うので良しとしよう。

そんなわけで作った。

珍しく日本語READMEもある。 BGM機能があるのは、YouTubeでよく見るものをリスペクトしたものであり、背景画像がほしければCSS編集でOKだ。

やっていることはごく単純で、Pandocで処理することを前提として一時ファイルを活用している。

プレーンテキストの場合はsedを使ってラインブロック化している。 この場合改行されなくなってしまうので、pre-wrapするようにデフォルトのスタイルシートで変更している。

スクロール制御はJavaScriptでものすごく入門的なコードだ。 右クリックでも再生・停止できるようにしているのは、コントロールをウィンドウフォーカスしてからでなくても行えるようにするためである。

ちなみに、今回のJavaScriptは互換性をあまり気にしない贅沢なコードでもある。 これはかなり新しいGtkWebkit、あるいはQtWebengineを使うという前提が成り立っているためだ。

解説

それでは恒例の初心者向けコード

JavaScript部分

せっかくなので、入門的なJavaScriptコードを解説しよう。

スクロール部分

まずスクロール自体はwindow.scroolByによって実現できる。

自動スクロールをするためにはこれを繰り返すようにしなくてはいけない。 もちろん、単純なループでもできるのだが、JavaScriptはシングルスレッドなので操作不能になってしまう。

このような反復はJavaScriptではタイマーイベントで行う。 タイマーにコールバック関数を登録することで、タイマー起動時にコールバック関数が実行される。 もし他の処理が実行中の場合は処理をキューに入れ、順番がきたら実行される。

反復の場合setIntervalのほうが簡単で、初心者向けの解説ではよくこちらが使われるが、 どちらかといえばタイマーイベントを都度登録するsetTimeoutのほうがコントロールしやすい。

関数オブジェクト、クロージャという考え方になれていないとそもそもコールバック関数が使えないので、ここはしっかりと理解しておく必要がある。

関数オブジェクトは実行可能なコード群をオブジェクト化したものである。 スイッチを押せば実行される物体になっているとでも思えばいい。 コールバック関数は、それを呼び出すタイミングでそのスイッチを押すように動作する。

setTimeout は指定した時間が経過したときにコールバックを行う。 コールバック関数の中で自身をコールバック関数とする setTimeout を呼ぶことでループさせることができる。

「スクロールの開始」はその関数を呼べば良い。 setTimeout で呼ばなくても一度呼べば setTimeout によってループする。

「スクロールの停止」は setTimeout をしなければ次回の実行がなされないため、停止する。 停止方法はタイマーをキャンセルするのではなく、次回のタイマーセットを行わないというものである。 このため、タイマー動作状態がonの場合のみ setTimeout を行う。

setInterval を使用した場合はタイマーをセット/キャンセルして制御する。

キーイベント部分

キーボードのキー入力は document あるいは window に対してイベントリスナーを設定する。

DOM Level1 のonKeydown を設定する場合の情報は割とあるのだが、 DOM Level3 の addEventListener を設定する情報はやや少ない。

コールバック関数の引数としては KeyboardEvent オブジェクトが渡される。 特定のキーをキャプチャするわけではなく、キーボード入力全てをキャプチャしてコールバック関数が呼び出される。 コールバック関数内でキーを判別する。

なお、コールバック関数が時間がかかるとフリーズしていると感じることになるため注意が必要。

キーの種別を取るための方法は色々あるのだが、 code が推奨される。 プリンタブルなキーに限定するのであれば key でも良い。 charcharCode はあまりうまく動作しないし、 keyCodewhich は廃止されている上に、プラットフォームに依存する。

それぞれどのような値になるのかは次のようなコードを書いて確認すれば良い。

元のキーの動作を無効にする場合は、第三引数を false として先にキーを捕捉してから Event.preventDefault によってバブリングを停止する。

右クリック禁止2、でお馴染み右クリックは contextmenu イベントになる3

スクロールスピード

スクロールは

  • スクロールする時間間隔が短くなると速くなる
  • 一度にスクロールする量が増えると速くなる

量が増えるとスムーズさが書けるため、時間を短くするほうが優先。 間隔が1(1ミリ秒)になった場合、加速はスクロール量によって行う。

逆に遅くするときはスクロール量が増えているならそちらを先に減らす。スクロール量が1であれば時間間隔を増やす。

1ミリ秒刻みでは使いにくかろうと思ったので、5ミリ秒刻み、ただし値が小さいほうが変化量は大きいため、5ミリ秒からは1ミリ秒で調整されるようにしている。 (50ミリ秒から+5された場合は10%遅くなるが、10ミリ秒から-5された場合は100%速くなる)

割合で増減させてもいいのだが、どちらかといえばキーリピートが効くため一定間隔にしたほうが良いUIであると考えられる。

今回は50ミリ秒をデフォルトとしたため、10%の5ミリ秒を増減単位とした。 なお、この速度感は画面のピクセル数によって異なり、特にピクセル数が多く高精細なディスプレイの場合は遅く、ディスプレイサイズが大きくピクセル数が少ない場合は速く感じることになる。

設計

基本的には「得意なことは得意な方法で」だ。

このようにスクロールやキーイベントなどはウェブブラウザとJavaScriptが簡単に書ける。 だから無理せずウェブブラウザとJavaScriptで書こうと考えたわけだ。

ただし余計な機能や情報があると使いにくい。 最低限のウェブブラウザが欲しいのだが、既にそのようなものはSurfがあるのでこれを使う。

もっとも、レンダリング部分はQtwebengineやGtkWebkitがあるのだから書くのは非常に簡単である。

もちろん、そのためにはテキストをHTMLにする必要がある。

テキストを正確にHTMLで表現するのはちょっと大変だが、CSSで white-space: pre-wrap にしてしまえばタグ要素と & をエスケープしてしまえば元のテキストを表現できる。 このようなことはSedでもできる。 ただし、 & を先にエスケープしなくてはならない。エスケープがエスケープされることを防ぐためだ。

テキスト処理するためのツールはLinux上に豊富にある。このようなことはシェルが得意とする部分だ。 文字列を埋め込むだけならば特別なツール(例えばeRuby)を使わなくても、ヒアドキュメントで十分だろう。 プログラムはシェルスクリプトで構築する、という方針は簡単に決められる。

中間的なファイルや生成に必要なファイルは、もちろん予め用意してリンクさせることもできるが、ディレクトリ設計に関する障害を増やすことになる。 今回はローカルディレクトリにインストールする、という前提を与えてはいるが、それでもできれば避けたいところだ。 それにバージョンアップの手間も考えれば、一時ファイルを作る方針にした。 これも簡単なものなのでヒアドキュメントで処理する。

ブラウザを作るにあたっては、私の得意なRubyではなく、割と苦手なPythonにした。 Rubyにもqml Rubyバインディングは存在するし、動作もするが、メンテナンスされておらず(3年間放置されている)、情報も非常に少ない。 また、ruby-qmlよりもpyqtのほうがqml自体もシンプルに書けるので、Pythonを採用した。

表示はウェブブラウザ(作ったもの的にはPython+qml+Webengine)で、スクロールはJavaScriptで、変換と橋渡しはシェルスクリプトで。 コンポーネントを分けて、それぞれが得意なことをシンプルに行う。 問題を簡単にし、ミスを減らすポイントでもある。


  1. もっとも、Unsurfを動かすためにはPyQt5とpython-openglが必要なので、ハードルの高さはどちらが上やら

  2. だいぶ懐かしい響きだが、今でもしているところはある。あまり意味はない。

  3. より正確にいえば、これはコンテキストメニューを表示させたときに発生するイベントで、右クリックと一対一ではない。キーボードのメニューキーを押した場合や、右クリック以外をコンテキストメニューキーにしている場合も同様にも発生するし、右クリックがコンテキストメニューでないのならば発生しない。

Linuxのターミナルエミュレータを比較してみた

ターミナルエミュレータにみんな不満を持っているようなのに、きちんと選んでない気がするので、比較。

メジャー編

挙動 Gnome Terminal Xfce4 Terminal MATE Terminal Konsole QTerminal Xterm
タブ Yes Yes Yes Yes Yes No
単一タブ時の表示 Hide Hide Hide Configuratable Configuratable
カラーテーマ Scheme & Edit Scheme & Edit Scheme & Edit per Profile (Scheme) Scheme Configuratable
背景画像 廃止 Yes Yes Yes (+Blur) Yes No?
背景透過 廃止 (外部から可能) Yes Single Color only Yes Yes Yes?
アプリケーション透過 No No No No Yes No
タブの色分け プロファイルごと Yes Yes Yes Yes
セル間隔調整 Yes Yes No No No No
ambiguous char Configuratable Configuratable FontConfig FontConfig FontConfig FontConfig
プロファイル Yes No Yes Yes No File
スクロール Yes Yes Yes Yes Yes Yes
バッファリミット Configuratable Configuratable Configuratable Configuratable Configuratable CLI Option
スクロールアップ時の新規出力 Configuratable Configuratable Keep Keep Scroll Scroll?
スクロールアップ時の入力 Configuratable Configuratable Scroll Scroll Scroll Scroll?
終了確認 No No No No Yes No
マルチタブでの終了確認 No Yes No Yes No
稼働中プロセスでの終了警告 List No List List No No
フォント 自由 自由 自由 QT monospace QT monospace 自由
Backspace Configuratable Configuratable & Auto Configuratable Keyboard Type Emulation ASCII DEL
Del Configuratable Configuratable & Auto Configuratable Keyboard Type Emulation \e[3~
単語選択文字設定 No Yes Yes Yes No Yes
画面分割 No No No No Yes No
開くディレクトリ Terminal Process Default Tab Current / Configuratable Terminal Process Default Terminal Process Default Terminal Process Default / Tab Current

Gnome TerminalとMATE Terminalはログイン端末にするかどうかの選択ができる。

XFce4 Terminalはダブルクリック時に選択する文字列や、ベルも設定可能でかなり細かい。 ただし、稼働プロセス警告やプロファイルはない。

KonsoleはURLヒントの表示、点滅テキストの制御などが可能。 マルチタブ終了もプロセス終了も警告される。

QTerminalは使いにくいポイントや配慮不足が色々ある割に、 ドロップダウン端末や、ショートカット設定、画面分割など独特な機能は持っている。 また、プロセス終了警告がなく、タブでプロセスが稼働している場合にタブを閉じると確認せずにタブを閉じる。

マイナー編

挙動 LXTerminal VTE3 Sakura Pantheon Terminal rxvt Unicode ST
タブ Yes No Yes Yes No No
単一タブ時の表示 Hide Configuratable Show
カラーテーマ Scheme & Edit ? Sceheme (ウィンドウ色は編集可能) Edit Edit CLI Option / Build Config
背景画像 No ? No No No? No
背景透過 No ? No Yes Yes? No
アプリケーション透過 No No? No No No No
タブの色分け No Yes No
セル間隔調整 No ? No No Yes No
ambiguous char FontConfig FontConfig FontConfig FontConfig FontConfig FontConfig
プロファイル No No? No No File / CLI Option No
スクロール Yes Yes Yes Yes Yes No
バッファリミット Configuratable ? Fixed Fixed Configuratable
スクロールアップ時の新規出力 Keep Keep? Keep Keep Keep
スクロールアップ時の入力 Scroll Scroll? Scroll Scroll Scroll
終了確認 No No No No No No
マルチタブでの終了確認 Yes No No
稼働中プロセスでの終了警告 No No No/Caution Only Caution Only No No
フォント 自由 ? 自由 自由 自由 CLI Option / Build Config
Backspace ASCII DEL ASCII DEL? ASCII DEL ASCII DEL ASCII DEL ASCII DEL
Del \e[3~ \e[3~? \e[3~ \e[3~ \e[3~ \e[3~
単語選択文字設定 Yes ? No No Yes No
画面分割 No ? No No No No
開くディレクトリ Tab Current Tab Current Home Directory

LXTerminalとPantheon Terminalは機能自体がすごく限定的だ。

VTE3については情報がなくて設定方法がわからなかった。 色んな端末が内部的に使っているので入ってはいるけれど、直接使う人はいなさそう。

Sakuraは設定できる項目がだいぶ少ない。Pantheonも同様でここらへんはユーザーが触れる項目を減らす思想か。

Pantheon Terminalは終了時に開いていた数だけタブを開く。 多分全くうれしくないが、設定可能である。

urxvtは何気にフォーカスオフ時に暗くすることもできたりする。

STはスクロールできないと言っているが、Shift+Pg{Up,Down}でできる…が、かなり端末以外の設定に依存してしまうためできないと思ったほうがよい。 STは非常にシンプルで、日本文化にはなじまないかなぁ。

おまけ: grml-zsh-config のグラデーションプロンプトテーマ

端末 表示
Gnome Terminal グラデーション、ただし幅がおかしい
XFce4 Terminal グラデーション
MATE Terminal グラデーション
Konsole 文字として表示
QTerminal 文字として表示
XTerm 文字として表示
LXTerminal グラデーション
VTE3 グラデーション
Sakura グラデーション
Pantheon Terminal グラデーション
LXTerminal グラデーション
rxvt Unicode 文字として表示
ST 文字として表示

比較してみて

XFce4 Terminalが非常に優秀。

おことわり

とりあえず試してみたというところなので、各端末の設定に関して知悉しているわけではない。

誤りや不足がある可能性がある。

  • 誤りの指摘
  • 比較して欲しい点の追加
  • 設定方法のレクチャー

などどしどしお寄せいただきたい。