昨今のブラウザ事情

ウェブブラウザとウェブテクノロジー

今やウェブブラウザは中核的ソフトウェアといって過言ではないだろう。 世界はウェブを中心に回っているのが現実だ。

だが、それは問題をふたつもたらしている。

ひとつは、過当競争だ。

あまりにもウェブに依存しすぎているがために、ウェブが高度技術化し、開発コストも増大しとてもついていくのが困難になっている。 現状ウェブ開発をリードしているのはGoogleであり、ChromiumによるBlink/V8エンジンが最も進んでいる状態だ。 これに対抗するのはMozillaのGecko/SpiderMonkeyで、Chromiumよりも進んだ実装を行うこともないではないものの、現実にはFirefoxに実装されChromiumに実装されない機能は大概標準化されないのが現実だ。 (ただし、標準化においてはある程度Mozillaが主導権を握る展開が続いている)

MicrosoftによるEdgeHTMLはこれと比べて明確に遅れをとっている。 これはちょっとした理由がある。 そもそもEdgeHTMLはWebKitをターゲットとしているのだが、WebKitは現代ではとてもではないが使い物にならない。

WebKitを開発しているのはAppleだし、そもそもWebKitはSafariのものなのだが、WebKit自体はオープンソースだし、他のソフトウェアも利用することができる。 とはいえqtwebkitに関しては既に廃止となっており、WebKitのバージョンも古い。

WebKitとBlinkを比べる良い手段はMidoriとFalkonを使用することだろう。 MidoriはAppleがcommitするWebKitGtk+を使用しており、一方Falkon(かつてのQupzilla)はBlinkを使用するQtWebEngineを使用している。 そして、Falkonで表示に困ることはないのだが、Midoriでは普通に「表示できないサイト」や「利用できないサイト」が存在するのだ。

根本的にWebKitはカジュアルでライトなウェブブラウジングに的を絞っていると考えて良い。 つまり、ちょっとした調べ物などであり、完全に表示できることよりも軽快であることを望むためのものであり、実際Safariは機能的にかなり限定的である。 最小限の機能を搭載することからも「ちょっとした行為」であり、目を尖らせてに向き合うものではないと考えているのがわかる。

実際、Microsoft Edgeもそのような考え方であり、機能的に貧弱だったInternet Explorerと比べても機能はさらに削られており、メニューは実に寂しい。

生殺与奪を握られたウェブエンジン

だが、この問題はなかなか複雑だ。

AppleとGoogleはこれらウェブエンジンを「自由に使わせなければならない」呪縛にとらわれている。

これはもともと、Appleが既にある程度成熟していたウェブエンジンに参入するにあたり、スクラッチから開発することをよしとせず、KHTML/KJS Softwareをベースにすることを選択したことある。 当時のKHTMLはLGPLだったので、ここから派生するためにはLGPLを継承せざるをえなかった。 もちろん、そのWebKitから派生したBlinkにしても同様にLGPLを継承するしかない。これにより望む望まざるに関わらず「開発したものは配布するためには公開し自由を保証しなければならない」ということになったのだ。

そのため均衡が保たれているのだが、実際技術標準というか、「ウェブの世界」そのものは主にはGoogle、そしてAppleの意向は完全に反映されるのであり、 世界をウェブが支配している以上世界の支配者として君臨する状況を許してしまっている。

これは、GoogleやAppleが「採用する」と決めた方針に反する方法がないという問題だ。 LGPLである以上、ウェブブラウザを「秘密」にしてしまったり、伏せられた邪悪な機能を搭載するのは難しい。 だが、正式にプライバシーを侵害するような機能、仕様を採用すると決定したとして(既にそのようなものがなくもないが)、それを覆すことができない。 もちろん、フォークするという選択肢はあるが、ウェブブラウザの規模と進歩を考えるとGoogle並の開発力で追従するということは現実的ではない。 結局のところ誰もがGoogle, Mozilla, Apple, Microsoftの少なくともいずれかには従わなければならないという状況にあるのだ。

実際、Chromeユーザーでも「Google及びChromeに対する信頼度」はかなり低いというアンケート結果がある。

唯一の良心といえるのがMozillaだが、Mozillaの体制や行動がプライバシー上の理由で批判されたことは一度や二度ではない。

結果的に我々の生殺与奪は彼らに握られているというのが現実であり、 そして現状においてはそれを覆すほどのリソースはどこにもないのだ。 これはOperaのような老舗ブラウザ屋がBlinkを採用し、WebKitの祖先であるKDE ProjectがQtWebEngineを採用していることからも明らかだろう。

セキュリティとプライバシー

もうひとつの問題はウェブを侵食するプライバシーの問題だ。

セキュリティについて昔と比べることは意味がない。

昔はセキュリティを脅かすものは見るからに怪しげな「悪人」であり、「怪しげなものを遠ざければ良い」というものだった。 また、そのようなセキュリティ上の問題は「プライバシーの問題」ではなかったのだ。

ところが現代においてはサービスを利用する上でプライバシーを侵害されることは前提であり、 それどころかウェブブラウザを利用することによってもプライバシーが侵害されるという状況にある。

なぜこのような状況になるのか。

まず、Facebookを筆頭にして、現在はプライバシーが主要な商品となりすぎていて、 どこもかしこもプライバシーを欲しがるという現状がある。 これはウェブの技術如何に依らず根本的な問題である。 「プライバシーを侵害したいと思う人がいなければプライバシーを侵害するものが作られることはない」のだから。

だが、彼らウェブブラウザデベロッパー達はこれらの「プライバシーを侵害したい」という要求に応えているし、 また彼ら自身がプライバシーの侵害を望んでもいる。GoogleやAppleが過剰かつ積極的に個人情報を収集している状況を忘れてはいけない。

我々は日々普通に使っているだけでも著しくプライバシーを侵害され続けている状況にあるのだ。

プライバシーを取り返せ

中には完全にプライバシーを保護するブラウザもなくはないが、代償は大きい。 そうではなく、普通は求めているのは「与えて良いと判断して選択し許可した以外のプライバシー侵害は認めない」というものだろう。

だが、これはなかなか難しい。 ウェブブラウザの根本的な機能として既にプライバシー侵害を可能にする機能が組み込まれているからだ。 例えばComodo Dragonはプライバシーを重視しているということだが(PrivDog事件もあったが)、トラッキングなどは普通に行えてしまう。

また、Vivaldiもプライバシーを重視しているが、それでも問題になっているプライバシーはあまり解決しない。 裏側で悪意ある行動をとっていないというだけで、知られないうちに何かが行われることを防いでくれるわけではないからだ。

ある程度、そして確実に効果がある方法は「セッションを残さない」ことだ。 トラッキングが最も驚異なのは、「アクティビティが同定でき」「蓄積されるから」だ。 蓄積されなければ同一人物なのか否かを特定することは困難になるし、取得可能な状況はある程度限定的になる。

Chromiumならば次のようにすれば最初からプライベートモードになるし、使うたびに情報はクリアされ、ある程度安心だ。

chromium --incognito

もちろん、これでTwitterとGoogleとFacebookに同時にログインしたら台無しである。 そんなことはせず、他のサービスを利用するときは必ずブラウザを閉じて行うべきだ。 これは、ログインしなくても、サイトごとにセッションを切るべきである

Vivaldiも--incognitoオプションを受け付けるため、Vivaldiを使えばさらに(いくらか)安全になる。 Linuxにおいてはデフォルトブラウザとして--incognitoつきでVivaldiを起動するようにしてしまうといい。 以下は私が使用している$HOME/.local/share/applications/incogvivaldi.desktopファイルだ。

[Desktop Entry]
Version=1.0
Name=Vivaldi Incognito
# Only KDE 4 seems to use GenericName, so we reuse the KDE strings.
GenericName=Web Browser (with Incongnito)
GenericName[ja]=ウェブブラウザ (with Incongnito)
Comment=Access the Internet (with safety)
Comment[ja]=インターネットに安全にアクセス
Exec=/usr/bin/vivaldi-stable --incognito %U
Terminal=false
Icon=vivaldi
Type=Application
Categories=Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml_xml;image/webp;x-scheme-handler/http;x-scheme-handler/https;x-scheme-handler/ftp;
Actions=new-private-window;

[Desktop Action new-private-window]
Name=New Incognito Window
Name[ja]=新しいシークレット ウィンドウ
Exec=/usr/bin/vivaldi-stable --incognito

デフォルトの.desktopファイルとの違いは以下の通り

  • 起動時に--incognitoオプションを付加
  • 日本語と英語のみにし、翻訳を排除(どうせ読めないし、ローカル設定だし)
  • new-windowアクションを除去し、デスクトップの右クリックメニューもIncognito限定に

これで開くアプリケーションの選択肢としてVivaldi Incongnitoが追加される。

プライバシーを強化する設定やプラグインを追加すればより万全だろう。

いちいちセッションを切るのは面倒だ、というまっとうな意見のために、私はMy Browser Chooserというソフトウェアを開発している。 サービスごとにプロファイルをわけてしまえば、サービス側がプロファイルを横断しての情報収集はできない。 運用ポリシーさえ守ればだいぶ楽になる。Zshスクリプトなので、Unix的な環境においてのみ機能する。

危ういスマートフォンブラウザのプライバシー

パソコンなら(特にLinuxならば)このようにいくらかの解決策を提示できる。 だが、本当に厄介なのはスマートフォンだ。

スマートフォンの場合ブラウザが握ることができる情報はパソコンの比ではない。 だが、にもかかわらずユーザーに与えられるコントロールは極めて少ない。

スマートフォン的な設計思想として、「可能な限りコントロール部品を減らす」というものがある。 例えばMicrosoft Edgeはメニューボタンがハンバーガーメニューになっておりドロワー式だ。これはタッチデバイス向けの設計であり、GNOME3もまた同様の設計になっている。 ドロワーに含まれるメニューも少なく、ここまでメニューを減らしているのは当然に相応に機能自体を削っているということである。 機能が多ければそれだけなんらかの煩雑さを持たざるをえないからだ。

このような設計にしている理由はふたつある。

ひとつはスマートフォンの狭い画面での煩雑性が操作性の低下に直結するためだ。 そして、もうひとつはユーザーが馬鹿でいられるようにである。

私はこのような考え方は好きではない。 なぜパソコン用のソフトウェアが低機能なスマートフォン設計を採用せねばならないのか?

このコントロールの少なさがプライバシーの問題にも直結している。 現在では必須ともいえるプライベートモードがひどく軽視されているし、ページを開く時点でプライベートモードで開く選択肢を与えられない。 スマートフォンはパソコンよりもアプリからリンクを開く機会が多いにもかかわらずだ。

もちろん、プロファイルの切り替えもサポートされていない。 結果的にスマートフォンに蓄積された情報が簡単に抜き取られてしまう状況である。 なお、ブラウザを使い分けたところでAndroidならば多くのブラウザはAndroidのWebEngineを使用しているため、中身はひとつ、結局は使い分けに意味などない。 iOSについてはあまり知らないが、おそらくは似たようなものだろう。自前でのウェブエンジン実装はあまりに困難だからだ。

ひどい話だと思う。 だがAndroid WebEngineとはつまるところBlinkであり、なかなか太刀打ちできるものではない。

使い分けるのであれば、Mozilla FirefoxとMicrosoft Edge、そしてBlink系ブラウザ(Chrome, Operaなどだ)を使い分けるという方法だ。 数が少ないのであまりリスク軽減はできないが、いくらかマシな方法だろう。

元は表現力も機能も安定性もひどいものだったAndroid Firefoxだが、現在はかなり改善されており、十分実用になる。 Quantam(Firefox 57以降)をもてはやす記事ほど素晴らしいものだとは思わないが、「Firefoxが実用になる」しいうのは極めて喜ばしいことだ。

それよりも推奨できるのはFirefox Focusを使用することだ。 Firefox Focusは常時プライベートモードのFirefoxである。firefox --private-window相当ということではなく、プライバシー保護のためにかなりenhanceされている。 ほとんどのブラウジングにおいてはFirefoxで困ることはなく、またアクティビティを保存する必要もない。 そして、Mozillaによって提供されるFirefox FocusはCM Security Browseなどを使うよりもよっぽど信用できると言える。

そう、ブラウザは重大なプライバシー資源となっているために「信用できるか」が極めて重要なのだ。 ましてスマートフォンブラウザならなおさらで、プライバシーの塊であるスマートフォンを狙ったアプリなど数知れずある。 言ってしまえば大部分は怪しいし、よほど信用できない限りは使えないのが現実である。 ブラウザはその基本的な動作においてほぼ全権を要求するという点も大きい。正常に動作させるために権限を与える必要があるためにリスクが高いソフトウェアなのだ。

言い換えれば、悪意ある人からすれば「これはブラウザです」というふうに言っておけば

スマートフォンブラウザの機能にも不満

典型的なのはOperaで、Operaは以前はかなり高機能なブラウザであった。 PCブラウジングやページ保存、印刷機能も備えていたのだ。

ところがそれらの機能は現在はもうない。スマートフォンには必要ないと判断されたのだろう。 だが、実際はOperaはもはや必要な機能が削除されてしまって使い物にならない。 このような「スマートフォンだから」という言い訳は、一体スマートフォンだからなんだというのかと思うほどに理由になっていない。

表示の難しいinspectionなどはまだしも、印刷、ページの保存、文字エンコーディングの選択、プラグイン、ページ検索、 ローカルファイルの取り扱いなどがスマートフォンにおいて欠けている必要があるのだろうか? それ以外にもウェブブラウザが様々に豊富な機能を備えているにもかかわらず、スマートフォン版ではない、あるいはコントロールする手段が与えられていない。 なぜスマートフォンではユーザーからコントロールを剥奪するのか。理解し難い。

Vivaldiのようなブラウザをスマートフォンに最適化させたようなものは出ないのだろうか。 一応、Vivaldiのスマートフォンバージョンの開発は行われていはいるようだが。

ハイアクセシブルウェブサイトとウェブデザイン (フォント関連)

font-familyの指定

font-familyにシステムデフォルトのフォントを並べているのを非常によく見る。 例えばYahoo! Japan

MSN Japan

Google (google.co.jp)

まず先に言うならば、Arialは欧文書体であり、フォント解釈を厳密に行う環境の場合、Arialが指定されることで文字化けが発生する。 ここではArialがないというケースを除外して次のように処理される。

  • Arialにグリフがないフォントを置き換える
  • Arialにグリフがないためフォント自体を置き換える
  • font-family自体を解釈せず既定のフォントで表示する
  • Arialのみで表示しようとする (グリフのない文字は文字化ける)

このうち最も困るのは最後のケースだが(Arialを指定したがために文字化ける)、実際は欧文をArialで表示し、和文を他のフォントで表示して「美しい」と感じるのは難しい1。それよりは全部和文書体の方がバランス的にもマシである可能性のほうが高いのだ。そのため、最初のケースも明らかに意図的でない限りはまずい動作をする。2

昔、ごく限られた条件下では、フォントが指定されないことに起因して文字化けるということがあった。 これは、ブラウザがデフォルトフォントを欧文フォントに決め打ちしており、フォントレンダラーによる文字選択は可能なので、指定しなければフォントレンダラーに選択を任せないために文字化けるという状況であった。

しかし、現状で考えると

  • 日本語版のWindows/Macであれば和文フォントがあり、メジャーなブラウザは和文フォントを選択する
  • 非日本語版でデフォルトの和文フォントがないのであれば、指定したところでそのフォントはないので使えない
  • 日本語環境を無視しているようなブラウザをわざわざ使用するユーザーは文字化けすれば設定すると思われる

ということから、システムデフォルトのフォントを指定することは 現実的に意味がない

強いて言えば、ヒラギノを優先して指定することで、Windowsユーザーでもモリサワ書体を購入しているユーザーにはヒラギノを優先して使わせる、ということも可能だが、それは「ヒラギノが他のどんな書体よりも美しい」というMaccerの思い込みに過ぎない。3

Mimir Yokohamaでは次のように指定している。4

通常フォントをサンセリフ体、本文フォントはセリフ体を指定している。 セリフ体のSource Han Serif JPを除くと全て商用フォントである。 これは、もしユーザーが商用フォントを持っているのであればそれを使ってもらおうということである。 本来のfont-familyの使い方であると言える。

適当に選択しているわけではなく、本文フォントとなるセリフ体には流れるようなグリフで、十分に収録グリフがあり、長文を読むのに疲れないフォントであることを選択基準にしている。 サンセリフ体についてはいわゆる「丸ゴシック」である。「丸ゴシック」という抽象フォントがないため、イメージとしてより好ましいフォントを並べる、という方式をとっている。もしあるのであればsans-serifではなくrounded-sanscjk-rounded-gothicのような指定がしたいところである。

font-family指定がシステムデフォルトフォントを指定するというのは、「システムデフォルトフォントが嫌いで、わざわざ商用フォントを入れて設定しているユーザーに対してシステムデフォルトフォントを強制する」ということでもある。 これはユーザービリティを高めているのではなく損ねている。 そんなことに貴重な数十バイトを使用するべきではないのではないか。

webfontについて

webfontはCSS 3.0で追加された、ウェブリソース上に配置されたフォントをダウンロードして使用するものである。 font-familyがシステムフォントしか指定できないために、結局システムデフォルトフォントばかり指定するという無意味に近い状況がこれによって改善された。

なんでこんなものが追加されたかというと、従来デザイン上特定のフォントを使用したい場合にどうしても「画像を使う」という状況であったが、W3Cとしては常に文字情報であればテキストとCSSを使うべしという思想である。 これを実現するためにCSSにテキストを重ねたり傾けたりして配置する機能と共に、特定のフォントを使わせる方法を提供したものである。

「デザイナーの意図するフォントを指定できるようにした」と解釈される場合も多いが、実のところそれは副次的なものであり、W3Cがこの仕様を制定した意図としては「テキスト画像を撲滅したい」ということであり、既にテキストとして表示されている情報がどのように表示されようが(W3Cにとっては)どうでも良いのだ。

だが、実際のところW3Cの意図に反して画像撲滅よりは従来からテキストで表示されていた部分のデザイナーの意図反映に使用されている5

このために「確実に好きなフォントが使える」程度の理由でwebfontが指定される傾向があるのだが、それはデザイナーの完全なエゴである。

欧文フォントであれば(W3Cが考えたように)ロゴ画像をダウンロードするのとさして差のないデータ量であり、それほど躊躇われるものではないのだが、和文フォントであると常用漢字のみ収録のものですら2MB程度ある。画像などよりもはるかに大きく、通信料金で考えると2円ほどかかる。 これを表示ごとに要求することになるのだ。6

しかも、そもそもフォントレンダラーは一種のバイトコードインタープリタであり、潜在的にはフォントファイルはウィルスとして機能しうる7

また、そうでなくてもテキストと異なるグリフを持つフォントをダウンロードさせることにより、コンピュータ(例えばGoogleやSymantecのチェック)を欺いてユーザーに嘘の情報を見せるサイトを作ることもできる。 これは詐欺などにおいて有効な手法である。

にも関わらず、現状主だったモバイルウェブブラウザにおいてはwebfontを無効化する機能というのはない。 私も仕事にしていたこともあるくらいだからフォントは大好きなのだが、それでも自分の望むデザインのためならユーザーに負担を強いたり、不快な思いをさせても構わないというデザイナーのエゴには賛同できない。

長文のための工夫

私が書くコンテンツは(この文章を含めて)往々にして長文である。

これは、意味ある情報を提供してこそ意味があるという思想に基づくもので、内容空疎なイメージ戦略や思考停止で選ばれるものを提供しようとは思っていないから…なのだが、長文を含めて読むのが得意な人は比較的少数だし、やはり長文を読むのはどうしても負担になりやすい。

そこで、可能な限り長文を読みやすいように心がけている。

本文に対する設定としては

  • フォントは細めで、流れるような(連続した文字を少ないコストで読める)明朝体
  • 自動カーニングで行間を詰める(長文の流し読みが楽になる)
  • これだけでは「文字量が多く黒い」と感じてしまうため、少しだけ文字間を空ける
  • 黒さを軽減するため、行間を少し空ける
  • 結果として段落間の行間が詰まってみえるため、段落間に空白をもたせる

このほか、リズム感のある句読点や、かぎかっこの使い方、言い回しの選択などの技法と組み合わせてできる限り「楽しく読める長文」を心がけている。

ウェブサイトは内容であって見てくれではない、ということを忘れてはいけない。


  1. この指定は「欧文のみの要素に対して欧文フォントを適用する」指定ではない。和文フォントが適用される条件でもArialのグリフがあるものはArialが使われるのだ。

  2. もちろん、欧文書体を和文書体に含まれていない特定のフォントを選択してほしいという理由で意図的にこのようなことをすることもできるが、その場合は和文書体よりも先に欧文書体を書くべきで、MS PGothicよりもArialが後、というのはArialの欧文よりMS PGothicの欧文のほうが好ましく、けれど和文書体にある欧文ではなくArialを使ってほしい、というよくわからない美的センスである。

  3. モリサワ書体を含め、商用フォントを選択肢とするのであれば、無条件に「ヒラギノが最高」ではなく、数多のフォントからそのサイト、その文章に適切なフォントを選択できるはずだ。

  4. Chienomiでは既存のWordPressテーマを使用しているため、私は関知していない。

  5. これは当然の帰結と言える。デザインされた画像を作成するのと比べて、CSSでそれを実現するのは難しいし、同じフォントであってもレンダリングで見た目に差が出ることから望むほどデザインを再現してもらえない。記述量も多く、しんどい。

  6. キャッシュがあるから、というのは傲慢である。特にモバイル環境ではキャッシュを取り直す状況は非常に多く、セッションごとに取得すると考えて間違いない。

  7. このために以前のWindowsではフォントインストールにセキュリティリスクがあるという警告が出されていた。

PureBuilder Simplyと新しいサイトのお話

PureBuilder Simply

デザイン

PureBuilder Simplyは従来とは大幅に考え方を変えた。

従来は基本的に「いっぺんの処理ですべて行う」というものであった。 このため、特に難しかったのが、ACCSにおける「前後の記事へのリンク」である。

PureBuilder Simplyは処理が分離されている。 一番基準となるスクリプトはデフォルトで全記事を処理する。 そして、全記事のメタデータをデータベースに書き出すのである。

従来はPureDocメタセクションに直接書くという方法をとってきた。 そのため、ドキュメントが処理時に変更されるのだが、これは扱いにくい側面が結構あった。

従来のPureBuilderはドキュメントごとに処理するようになっており、 メタデータはドキュメントにある。 そのため、処理時には「そのドキュメントのメタデータしか知らない」状態であった。

今回のPureBuilderもすべてのドキュメントのメタデータを読み込むことはしないが、 すべてのドキュメントのメタデータの書き出しは行う。

メインスクリプト以外については、このスクリプトが書き出したデータベースに基づいて処理を行うため、 すべてのドキュメントのメタデータを知った状態で処理することができる。

Frontmatter

もともとPureBuilderはPureDocを前提としていて、Markdown supportはPureBuilder2で採用された。

Markdown Supportを採用したのはWindowser向けのフレンドリーシュガーであり、 Mimir Yokohamaでサービスを展開するにあたって、記述の難しいPureDocではなく、 記述しやすいMarkdownで書けるようにすることで「ユーザーによる更新の容易さ」を向上させる目的があった。

この時点でMarkdown YAML Frontmatterのことを知らなかった。 そのため、従来のPureBuilderではMarkdownドキュメント中にHTMLコメントを入れ、その中にPureDoc meta headerを入れるという仕様になっていた。

だが、そもそもMarkdownにYAMLでメタデータを書ける仕様である。 同じYAMLのメタデータなのだから、これに従うべきだ。

そのため、PureBuilder SimplyではMarkdownドキュメントのFrontmatterを必須としており、 frontmatterが存在する前提で処理する。 (titleメタデータが必須であるため、どのみちfrontmatterは必須となる)

さらにReStructured Textに対応したが、これも先頭にコメントを入れてYAMLでヘッダを書く、という仕様とした。 次のような具合である。

ReSTなら

Pandoc

PureBuilder Simplyはドキュメント処理をPandocにゆだねている。

これは別に手抜きというわけではない。従来にしてもMarkdownの処理はKramdownによって行っているのであり、 PureDocの実装は別なので特にPandoc採用でアウトソーシングしたという感はない。

Pandocの利便性と「標準性」から、「Pandocを主としてPureBuilderは補助であるほうがユーザービリティが高い」と判断したのだ。

PureBuilder Refinedでは新しいPureDoc Zをサポートする予定だが、 PureBuilder Refined自体がPureBuilder Simplyでは不足の場合に限られるので微妙かもしれない。

「事前生成」戦略

PureBuilderは言葉の意味としてはCMSで合っているのだが、どちらかというとCCS(Content construction system)に近い。 基本的に生成機能だけで、管理に関してはシステムの標準的機能でなるべく簡単てにできるようにしている。

一般的なCMSとの最大の違いは、「Webアプリケーションとして動作しない」ということだろう。 原則としてPureBuilderは(ホームページビルダーなどで書いた場合と同様に)ローカル環境でウェブページを組み上げ、そのままアップロードすることで動作する。

従来のPureBuilderにあった、Webアプリケーションとして動的に生成するためのプラガブルな仕様は現時点ではPureBuilder Simplyにはない。 予定もされていない。単一ページのサポートは限定的で、原則としてディレクトリ単位でビルドを行う。 全体ビルド機能も排除された。

より「サイトを構築するためのスクリプト」という点に特化した。

私のウェブコンテンツ生成は可能な限り「事前生成戦略」をとっている。 通常、ページは書く回数よりも読まれる回数が多いので、コストのかかる処理は1度だけ行いたい、という方式だ。

これは構造的に最速の方式でもある。

ウェブサイトの仕組みを考えればわかるが、たとえばWordPressでは

  1. ウェブサーバーが接続を受け付ける
  2. ウェブサーバーがPHPプロセスにWordPressを渡す
  3. WordPressがデータベースにアクセスする
  4. データベースから必要なデータを受け取ったWordPressがページを生成して返す
  5. ウェブサーバーが応答する

という手順になる。 WordPressのキャッシュ機能ではWordPressはデータベースから受け取った結果を処理せずにそのまま応答するため、高速化するのだが、 それでもこの接続にかかる時間が決して小さくない。

対して、静的ファイルならば

  1. ウェブサーバーが接続を受け付ける
  2. ウェブサーバーがファイルを読み込んで応答する

とプロセスが少なくなり、より高速だ。 WordPressの高速化手法も、PureBuilderが同様の手法を適用すればさらに高速する。

さらに、ウェブサーバーにとって静的ファイルの応答は基本的機能であるため、 より高速なウェブサーバーが選択できる、というメリットがある1

また、静的ファイルのみでウェブサイトの構築が可能なことで、ウェブサーバーの選択肢が増える。 PHPが動作しないGeocitiesやGitHub Pagesでも構築可能だ。

Mimir Yokohama新サイト

新サイト開設

Mimir Yokohamaの新ウェブサイト開設は、主に「異様にサイトが重くなっている」という事情からきているのだが、 実はそもそもPureBuilder Simplyはこの新サイト構築のために書き直した。

Aki SIE新サイト開設時もそのためにPureBuilder2を作ったのだが、 PureBuilder2が6ヶ月も要したのに対して、作業時間で4日、経過時間でも9日と非常に速く書き上がった。 やはりデザインは大事だ。

そして当然ながら、Mimir YokohamaウェブサイトがPureBuilder Simplyのデビュー戦となった。

「楽」という言葉の意味

Mimir Yokohamaのウェブサイトの出来には非常に満足している。

だが、この開発において“PureBuilder Simplyの開発”は全行程における30%程度でしかなかった。

PureBuilder Simplyを使ったサイトは非常に「楽」であり、「簡単」なのだが、誤解してはいけない部分がある。

今回はWordPressからの移行であるため、WordPressで利用している機能に近い状態を狙った。 デザイン的にも近く、バックエンドの変更や、それによって品質が低下した印象を与えないようにしている。

まず言っておくと、「WordPressのサイトを欲している」のであれば、PureBuilderを採用するよりも、 WordPressを採用したほうが確実に楽にできる。 なぜならば、そもそも欲しているのはWordPressなのだから、WordPressよりも楽にはならない。

そもそもPureBuilder Simplyによる構築と、WordPressによる構築はちょっと話が違うのだ。

WordPressの場合、テーマ機能やプラグインなどは既に揃っている段階から話をはじめる。 PureBuilder SimplyはそもそもWordPressではできない完全なカスタマイズを実現するという前提があり、 WordPressで言えばテーマやプラグイン、CSSなどを「すべて0から記述するところからはじめる」というのと同じ位置にある。

もしもWordPressをその位置ではじめるという形で条件を揃えたならば、PureBuilder Simplyのほうが「楽だ」と断言できる。

実際はそのような条件では比べないと思うのだが、逆にWordPressに合わせて構造やビルドの仕組み、テンプレートやCSSなどがすべて揃った状態からはじめるならば、 これもPureBuilderとしてはそこまで分の悪い勝負ではない。

なぜならばその状態で必要なことは

  • 文書を配置したい場所に新しくファイルを作り、MarkdownまたはReSTで書く
  • PureBuilderのバッチスクリプトを実行する
  • Gitでcommit&pushする

というだけのことだからだ。

「設定ファイルを書く」「コマンドを実行する」というあたりに、「Unixer的な楽さ」の感覚があるが、 これに関しても別にお客様に納品するときにはちょちょいと調整すれば良い話だ。 若干手順が多いようにも感じられるが、実際はWordPressの場合は

  • ログインページにアクセスしてログインする
  • ダッシュボードから新規記事の投稿を選択する
  • ページ上で文章を書き、タイトルやカテゴリなどを選択する
  • 投稿ボタンを押す

という手順で、慣れてしまえば麻痺するが、かなり手順は多い。 私が使っているWordPressサーバーは遅く、1クリックあたり1分とか待たされるので、 「WordPressは手順が多くて面倒」という印象が強い。 あちこち飛んではキーボードとマウスを持ち帰るUIも嫌いだ。

もし、PureBuilder Simplyでできることと相当のものとして、 「WordPressもデザインや挙動をカスタマイズする」 という条件にしたならば、これはPureBuilder Simplyが有利だろう。

PureBuilder Simplyを採用するのは「入り口」

だが、実際はPureBuilder Simplyの採用というのは全行程においてそこまで大きなものではない。 おそらく、PureBuilder Simplyのデフォルトで作られたサイトには誰もが失望するだろう。

PureBuilder Simplyの場合、「テンプレート」と「CSS」という要素がある。 これを書くのは、PureBuilder Simplyで「簡単にしている」部分ではないところであり、技術者の腕のみせどころだ。

最近はwebといってもCMSありきのエンジニアが増えていて、HTMLやCSSを直接記述することができない人が増えている。 だが、それはCMSの枠の中でしか仕事ができていない。 PureBuilder Simplyはそれをイチから作るのであり、ウェブデザイナーとエンジニアの腕の見せ所だ。

PureBuilder SimplyのテンプレートはPandocのHTMLテンプレートである。 ただし、「Pandocの出力に対してeRubyで処理できる」ようになっている。 結果、テンプレートの展開は2度行われる。

Pandocのテンプレート機能は意外なほど強力だが、 「値が○○だったら」という式はかけない。

eRubyは完全なプログラムであり、「なんでもあり」である。

比較的単純な(PHPやSSLで行うような)ものに関してはPandocテンプレートで処理できる。 実際、現時点でMimir YokohamaのウェブサイトはeRubyでの処理を無効にしている。

PureBuilder Simplyにおけるテンプレートの作成は「若干の、もしくは本格的なロジックを含むHTMLテンプレートを書く」という作業である。 もちろん、それはデザインが必要であり、CSSと連動した「ページ設計」が必要となる。 ページ設計はかなりエンジニアリングレベルの高い作業だし、 最も単純にはデフォルトテンプレートを使っても良いのだが

CSSと連動した高度なロジックを使いたいといった場合には難易度は上がる。

プログラミングではないけれど、ロジカルに考える

もちろん、CSSを書くのはプログラミングに近い次元になってくる場合もある。

今回のMimir YokohamaのウェブサイトはハンバーガーメニューとドロワーについてはJavaScriptを一切使用していない。 これはAki SIEウェブサイトで使用されていたものの改善版である。

だがそのために、配置や仕組みに関してはかなりロジックが含まれている。 CSSにはロジックはほとんど含まれないが、「ロジックをほとんど含むことのできないものによって動的なフローを実現する方法」を考えるところにロジックが行使されているのだ。

プロモーションモードのページでは下からフェードインするようなページデザインになっているが、 これもJavaScriptは使用していない。

これは単純にHTMLとCSSで実現するウェブサイトを構築するときに、 「単に書くのではなく、そこにロジックを含んだ構造をもたせる」ときに必要となるものだ。

PureBuilder Simplyはウェブサイト構築ツールであって、 デザインに関しては感知しない。 だから、そこに関しては「自分で作る」必要があるのだ。

今回も難易度や作業量としては、テンプレートとCSSを書くことのほうが大きかった。

PureBuilderはサイトの内容については感知しないのだから、別にJavaScriptを含んでもいい。 特にそれを禁止はしていないし、支援もしていない。 別にWordPressのクローンを作ることも、できなくはないのだ。

「サイトを構築する」手間で考えると…

単純に「見栄えするサイトを作りたい」という条件で考えた場合、 WordPressのほうがずっと楽だ。 なぜならば、デザインやロジックが既に存在していて、それを選ぶだけだからだ。

PureBuilderが担っている部分に関してはWordPressよりも楽かもしれないが、 WordPressにはあるがPureBuilderにはない部分がある。 それについてはどうしてもWordPressでは発生しない労力を払わざるをえない。

だから、サイトを構築する手間がWordPressよりも軽いということはない。 WordPressのインストールの労力を含めてもだ。

だが、そのような「敷居の低さ」を求める人がPureBuilder Simplyを自らインストールしてサイトを構築することは想定していない。 PureBuilder Simplyで自ら構築する人は、そんなものがなかったとしてもテンプレートを書き、CSSを書き、JavaScriptを書く人だ。 私がお客様にPureBuilderの簡便性を説くときは、そのような想定で話しているわけではない。 構築はこちらで行って、更新をお客様がされる際には難しくない、ということを言っているのだ。

テンプレートやCSSやJavaScriptは自分で書く、という前提のもとでは、PureBuilder Simplyの採用はかなり労力を削減することができる。 PureBuilder2と比べ管理の手間もかなり減り、非常に楽になった。

新サイトのデザイン、ポリシー

PureBuilderの強みは事前生成による高速性である。

さらにMimir Yokohamaでもポリシーとしている「軽量さ」と「アクセシビリティ」に重きをおいたデザインとなっている。

ただし、Aki SIEのウェブサイトは発想力をアピールする意図もあったのだが、デザインがちょっと古くさい2。 今回Mimir Yokohamaのサイトではよりモダンなデザインを採用することにした。

といっても、そのデザインはほとんどがWordPressで使用していたテーマのビジュアルを踏襲している。 ただし、全く同じというわけではなく、もとがシンプルなデザインであったために「ブロックごとに端までボーダーをひっぱる」「白に対してグレーのラインを引くモノトーン調」「右側サイドバーの2カラム」といったことを踏襲しているだけで、 メニューデザインなどは異なるし、実はカラーテーマも違う。 このあたりは「変えることが目的だった」わけではなく、そもそももとのブログでもカスタマイズしたかった部分なのだ。

ちなみに、ブログではそんなシンプルなデザインであるにもかかわらず、ちょっと古い環境(IEなど)では表示が崩れる。 なんでその程度のもので崩れてしまうのか、私には疑問でならない。

前述の通り、ハンバーガーメニューやフェードインテキストなどはCSSで記述されている。 これは、主に次のような意図だ。

  • JavaScript禁止の環境や、JavaScriptを搭載しないブラウザでもエクスペリエンスを損ねない
  • JavaScriptを使用していない分容量的に軽量
  • HTMLを「意味」を欠落させない

ただし、古いブラウザでのエクスペリエンスは若干犠牲になっている。 だが、それは「アニメーションが表示されない」程度の話で、表示自体はChrome 1.0, Firefox 1.7, Opera 9.0, Safari 3.1で対応している。 あまり言いたくはないが、IEは9.0からの対応だ。

実は今回のサイトではHTML中に同じメニューが2回登場する。これは、上記環境よりも古い環境においてはドロワーが表示できない代わりにサイドバーにメニューを表示させるようにするためだ。 これはアクセシビリティのための処置だが、場合によっては1kB程度はサイズが増加するため、ちょっと残念なところだ。 このメニューはごく初期のCSSしかサポートしない環境でも正常に表示される。 CSSを全くサポートしない環境の場合、メニューは2つ表示される。 この場合上のメニューは記事タイトルよりも上になり、高さもあるため見栄えしないが、そのような環境では仕方ないし、十分許容範囲だろう。 むしろタイトルと記事の間に入るよりはずっと良いと考えられる。

軽量性重視だが、従来と違い飾りとしての画像がところどころに入っている。 従来があまりにも殺風景すぎたという反省であり、このあたりはブログの時点で投入しているものを継承している。

プロモーションページの実現

全く印象の異なるプロモーションページだが、書き方はほとんど同じである。 別にテンプレートをかき分けることもしていないし、普通にMarkdownで書かれたページだ。

プロモーションページの印象の違いは、テンプレートにおける若干の工夫と、CSSによって実現されている。 frontmatterでプロモーションページであることを指定すると、Pandocテンプレートによってそれがクラス設定される。 あとはそのクラス設定に基づいてCSSで見せたくない要素を消去し、一部レイアウトを変更する。

こうした発想力は、やっぱりロジカルシンキングなのだ。

プロモーションページもかなりシンプルだが、 見出しには画像を使いたかった、という気持ちがある。

そうしていないのは、「適切な画像」の選定が非常に困難だったことと、 ヘッダーごとに画像を選択するためにはそれなりにあまりスマートでない余計なロジックを追加する必要があったからだ。

もしもこれぞという画像があれば採用することだろう。

ちなみに、プロモーションページはスマートフォンの商品プロモーションページをイメージしている。 なるべく説明的にならないようにしたのだが、後に書いたものほど説明的になってしまった。 どこまでイメージで語り、どこまで具体的に語るかは難しいところだ。

速度

実際のところ、Mimir Yokohamaにおける制作ポリシーと同一ポリシーで制作したのであり、「最速を目指す」という方式ではない。3

だがそれでも、旧WordPressサイトの10倍程度の速度になっている。 高速化のために使用した手段は以下のようなものだ

高速なサーバーを選択
ConoHaはSSDを採用しており、ネットワーク帯域も太く高速だ。 Nginxを採用
静的ファイルの応答に関してはNginxは最速に近い コンパクトなHTML
できるだけ冗長な表現を避けてコンパクトなHTMLが生成されるようにした。ただし、アクセシビリティを優先してメニューは重複している 可能な限りCSS
JavaScriptなしで動作するようにしたのは「JavaScript無効というオプションを与えるため」だが、ロジックの最適化によってある程度の容量削減に繋がっている WebP
WebPをサポートするのはChrome/Chromium系列だけだが、WebPは「アルファチャンネルつきロッシー圧縮」が可能なため、PNGよりもだいぶ軽くなる。一部PNG画像についてはobjectタグによりWebPを優先して使用するようにしている。アクセシビリティを重視し、重要な画像ではこの処理は行われずimg画像を使用している。 画像よりもCSS
「デザインはセンスでがんばる」方式で、画像などのアイテムの使用数は非常に少ない。寂しさはグラデーションで埋めているが、華やかさに欠ける感は否めない。

高速性ということでいえば、「CSSが重い」ということは感じるが、改善は若干難しい。 もちろん、minifyなどのテクニックである程度は小さくなるが、保守性を重視しているためだ。

また、CSSを3つから1つに減らすというアイディアもあったのだが、比較的サイズの大きいファイルであり、並列ダウンロードしてもらったほうが速いことから分割に戻した。

ミーミルのロゴなどは埋め込んだほうが高速化するだろうが、軽量化には寄与しないし、アクセシビリティが下がるので実施していない。 トップページで51.5KB、低速なうちの環境でTTFBは14.08ms、DNS lookupとfaviconを除いた時間は101.36msとなった。 従来が500kB/5s程度だったことを考えると、この計測では1/10の容量、50倍の高速化となっている。

MarkdownとReST

今回、Pandocの採用によってMarkdown以外のソースフォーマットに対応することが可能になった。 そして、最初に採用したのがReStructured Text(ReST)である。

Pandocがサポートする中で最もMarkdownに近い汎用性があるのはReSTである。 他にそのようなフォーマットはないが、あるいは専門分野での記述用にDocBookなどをサポートする可能性はある。

なお、入力ソースとしてのHTMLは、判別しがたさの観点からサポートは行わない。

ReSTはMarkdownと比べて表現力に優れている。 記述の簡便性も「好みの問題」と言えるような差異だ。 ただし、ReSTが優れている点について必ずしもそのまま適用できるわけではない。 なぜならばPandocがReSTをフルサポートしていないからだ。

実際のところ他フォーマットへの変換を想定しないのであれば、HTMLを直接記述できるMarkdownの優位性は揺らがない。


  1. 今回はNginxを使ったが、基本的にNginxも静的HTMLファイル向けのサーバーで、アプリケーションは他のサーバーに接続するリバースプロキシとして動作する方式だ。Thinなどを使う手もあるかもしれないが、Nginxよりも高速化するかは疑問。

  2. 800pxのブロックが中央にフロートしているデザインは2005年ころから流行したブログデザインと類似のものだ。今でもamebloなんかはこのデザインなのだが、新規にサイト立ち上げると画面めいっぱいまで使うデザインがデフォルトになっている。

  3. 最速を目指すのであればコードゴルフやminified、画像の排除や機能の統一化なども考えられる。実際のところ「速度は上がるがアクセシビリティが下がる」方式は取ってないし、コスト過剰にもならないようにしている。

当サイトがウィルスバスターにブロックされる件について

当サイトがウィルスバスターによってブロックされる、という話は去年にもう聞き及んでいたのだが、その時点ではSSL証明書がルート認証局の署名をとっていないのが原因だろうと判断し、HTTPSでのアクセスをできないようにした。だが、2/16に依然としてブロックされるという情報が入り、調査したところ、どうやらウィルスバスターの「よくある誤検知」であるらしい。


同様に誤検知された方のブログ

このサイトはまだ、iPhoneのJailBreak(自身のiPhoneに標準でかけられている操作上の制約を解除し、iPhoneの管理者権限を取得する)に関する話題を取り扱っているのでわかるといえばわかるが、まっさらなサイトがターゲットにされることも。


新しく取得したドメインに初めてアクセスしたら、ウイルスバスターに「安全ではない」と警告された!

ウィルスバイターの(トレンドマイクロの)暴挙は有名で、

Slashdotで記事にもなっている

そもそも、スパムとウィルスの配布を行っているサイトだと言うのだが、当サイトはメールマガジンの配布すらしておらず、ドメインはスタッフのみが所有する。また、当サイトは何らソフトウェアの配布を行っていない。極めて言いがかりだ。

トレンドマイクロは頻繁に政治的圧力をかける。例えば2014年秋にはキュレーションサービス(2chやTwitterなどの発言をまとめたサイト)を一斉に有害なコンテンツのサイトと認定、そのほかWindowsの詳細設定を変更するツールをウィルスとみなし、最も危険なソフトウェアはCRPM解除ツールだと言う。

ちなみに、CRPM解除ツールを説明すると、いわゆるcopybreak、コピー防止機能を無効化するためのものである。日本においてはその配布、使用共に違法だが、本来私的複製は認められるべきものであり(日本ではデジタルデータの私的複製自体を禁止している)、これを禁止している先進国は日本くらいのものである。そして、トレンドマイクロは決して日本ローカルな企業ではない。

仮に倫理的側面で反対するという立場をとるにしても、それが「セキュリティ上脅威である」という判定は著しく不当である。「あいつのやり方は嫌いだ」という理由で「あいつは詐欺をしている」と社会的信用を背景として吹聴しているのだから。

風評被害を振りまいた上で「やめてほしければ金を払え」というやり方はひどいものだと思う。この「金を払え」はトレンドマイクロに直接支払うものではないが、かなりの金額である。当然ながらそのようなことができるのは大手だけであり、

そもそも風評被害を振りまいて、やめてほしければ金を払えというのは「反社会敵勢力のやり方」ではなかったのか?

まずは異議申し立てを行った。改善がみられなければ、訴訟しかあるまい。

HARUKA Sound/Aki SI&Eの正木と申します。

当サイトが危険である、との判定によって業務に多大な支障が出ております。

当サイトは所有するドメインによるメールアドレスは現在すべてスタッフ所有のものであり、メールマガジン、メーリングリストを含むマルチキャスティングは一切行っておりません。

また、サイト上でプログラムの配信を行っている事実もなく、技術的な内容の記載、業務のご案内を行っているものです。

早急に修正されますようお願い申し上げます。

Vivaldi Browser

Vivaldi Browserは新しいウェブブラウザであり、現在はまだテスト段階にある。

Vivaldi Browserの生い立ちとしては、もともとOpera Software ASAのCEOだったヨン・スティーブンソン・フォン・テッツナー(テッちゃん)が、My Opera閉鎖に不満を持ち、それに代わるポータルサイトとしてVivaldiを作ったことが最初のようだ。

コミュニティは2014-03に誕生しているが、2015-01-27にOperaに代わる新たなるウェブブラウザ、Vivaldiを誕生させた。

Vivaldiの特徴は次のようなもの。

  • OperaがPrestoからBlinkへ移行する過程で失った機能を復活させる。例えばMUA
  • タブを大量に開くユーザーを対象とする
  • 高速
  • Chromiumベース
  • とてもバグかが多い(既に3件リポート済み)
  • Windows/Mac/Linuxをサポート

驚いたことに、2015-01-31の時点で既にAURにはあり、今日確認したところPCLinuxOSの64bitリポジトリにもあった。Tchnical Previewと言いながら、スクリプト名はvivaldi-stableである。

使ってみて思ったのだが、非常にバグが多く未完成な印象を受ける一方、本当に速い。Opera Developerよりも明らかに速い。ただし、Blinkブラウザ共通の症状として、私のLinuxデスクトップで使っていると高負荷となりプチフリーズを生じやすくなり、非常にストレスあるブラウジングになる。

このバグレポートのためにここ数日英語漬けになっている気がする。

しかし、昔はウェブブラウザとは随分とわくわくしたものだが、久しぶりに未来を夢想してしまうようなソフトウェアが登場した。

某コンテストの投票方式の問題点

先日まで某サイトでwebコンテストが実施されていた。だが、これにかなりの技術的問題点があったので、言及しておく。

会員に対する投票と、一般の投票は、票の重さが違う、という仕様で、一般投票は1日に1票、ということだった。しかし、この重複票排除というのは、現実にはまず不可能である、とされている。

重複票排除については1995年頃から議論されていた。1人1票、と設定しても、どうやってその人が既に投票したかを確認するか?ということだ。方法としては、IP, IP+UA, Cookie, 登録制が一般的だった。

IPはゲートウェイホストによって個々のインターネットホストに与えられるため、同一IPの投票を重複とみなす、という方式だ。だが、この方式は、インターネットカフェやケータイ(これは2000年以降)で問題が生じることと、NATを用いるために同一世帯の家族を「重複票とみなしてしまう」という問題があった。一方、PPPならば「電話をかけ直す」ことでIPアドレスは振られ直すことが多く、この重複を排除できない。

IP+UAは、IPとUAの両方が一致する場合重複とみなす、というもので、会社、ネットカフェなど共有回線がまるごと重複とみなされる問題を回避しようとした。しかし、UAは当時は特にバリエーションがそれほど多くなかった上に、詐称することも可能だったため、会社などそれなりの規模になるとかなりの確率で、環境を揃えているネカフェではほぼ確実に重複とみなされ、一方重複投票したい人は容易に回避できた。

Cookie方式はブラウザに「投票した」という情報をもたせることで管理しようというものだ。比較的単純で効果があったが、手元に複数の、Cookieを共有しないブラウザがあれば回避されてしまうし、単にCookieを削除するだけでいくらでも投票できてしまう。

登録制は、重複登録をいかにして防ぐかが問題となる。また、登録制にすることでハードルが上がり、投票数は劇的に低下する。重複票を防ぐ効果は低く、それでいてむしろ避けられることになるため、よほど自信のある(中身にというよりも、popularityにおいて)プロバイダでなければ採用は逆効果だった。

これらの問題の難しさを諦めて、逆手にとったのがAKB方式といえる。つまり、重複投票はしても構わないが、その票数は買わなければならない口数方式だ。

例えば住基カードを使えば1人1票は実現可能だが、厳密性を求めるならなりすましの対策という非常に困難な問題にぶつかることになる。それに、選挙でもなければ同定に住基カードなど使えない。

携帯電話に限る、という方式はお手軽であり、普及している。電話番号を使うことで同定できるためだ。だが、そのような理由でコンテンツを携帯電話に限ることは、アクセシビリティの観点から言っても好ましくないし、やはりアクセスはかなり減少する。それに、そのような目的で電話番号を取得するのはいかがなものか?ということもある。

このほか、TwitterやFacebook, Google+のようなopenIDを使って認証する、という方式もある。電話番号よりはいくらかソフトなやり方だが、その分効果は低下する。

このように非常に難しい重複投票の制限だが、そのコンテストでは、単純にCookieを使う方式だった。CSRF対策か、セッションクッキーを使うようになっていたが、その場合、単純にブラウザのプライベートウィンドウを開いてアクセスし、投票して閉じれば無限投票が可能だ。

もっとあげつないやり方としては、curlなどでセッションクッキーを保存するようにして投票ページを取得したあと、投票するという2回のコネクションを張るだけで投票できる。この間0.1-3.0sec程度なので(私の環境で)、ループすれば1時間で1500票は入れられる。

これはさすがに中止になるか無効になるかするように思う。

もう少し考えて作ってもよかったのではないだろうか。

HTML * CSS 美しいフレームをもつカラムスタイルレイアウトの難しさ

私のサイトをみるとわかるのだが、ボーダーが画像になっている。これをどうやって作るのか、というとごくごく単純で、背景画像を持つdiv要素に入れ子で白背景のdiv要素をおいているだけだ。ちなみに、外側のdiv要素にpaddingを設定するのが正しいやり方だ。

ところが、これで左右カラムを置き、しかもその中にブロック要素をおこうとするとかなり難しい。floatを使って配置すると、内側のブロック要素は親要素のブロックを突き抜けてくっついてしまうのだ。普通なら左右カラムはくっついて配置されて構わないものだから、このような挙動は気にしないのだが、今回の場合、左右カラムの間に空間を作ってボーダーを表示したいため、工夫がいる。

とりあえず、まずは縦に並ぶブロックを分けろ、だ。左右カラムはブロックの中に入れて左右分割すべきだ。でないととても苦労する。

さて、問題の比較的単純な解決策はfloatを使い、左右それぞれにfloatし、かつ重ならないようにwidthを設定する方法だ。だが、私はfloatを使う方法があまり好きでない。なんらかの理由で重なってしまうと後に書いたブロックは後ろにいってしまうという、表示への影響が大きいからだ。

そのため、私がとった方法は

  1. static配置では中のブロックに対してabsoluteが使えないので外のコンテナはrelativeで配置
  2. 右に配置されるサイドバーコンテナを先に書く
  3. サイドバーコンテナはabosluteで配置。widthz-indexを設定
  4. メイン部分コンテナはrelativeで配置。同様にwidthz-indexを設定
  5. サイドバーコンテナ、メイン部分コンテナ共に内側に入れ子のコンテナを配置(白背景)
  6. 外のコンテナのwidthpaddingでボーダーを適切にする。つまりギリギリにしないほうが良い
  7. サイドバーコンテナにmax-height、メイン部分コンテナにmin-heightを設定。サイドバーコンテナはoverflow: auto

簡単な話なのに複雑、と感じただろうか。実はそう簡単ではない。確実に正確な位置に配置しようとすると、floatしないならabsoluteで置くしかない。ところが、そうしようとするとstaticのまま親コンテナが配置されていてはいけない。

サイドバーコンテナを先にするのも理由はあるが、別に好みだとは言える。

widthの設定はもちろんかさならないように、またボーダーのサイズを調整するためで、z-indexは万一重なった時のためだ。

入れ子にするのは白背景とボーダー調整のためだが、この方法ではなくてもできる。

さて、なぜ両方absoluteにしないかというと、そうするとこのブロックは高さ0であるとみなされ、下側のボーダーが出ない(下にフッターを配置した場合、それも出ない)。そのため無限に長くなるメインのほうをrelativeにしているのだが、そうすると本文よりもサイドバーが長くなるときに支障が出る。そこで、サイドバーの最大長を制限すると共に、本文の最低長を要求することで、サイドバーのほうが長くならないようにしている。

別に「すごく難しい」という話ではないのだが、これはなかなか出てこない話だ。というのは、かなり技術的なことをしているが、それは構造的、意味的なものではなく、完全にデザインのための記述だ。デザインのための技法というのは技術者にはなかなか身につかない。そして、デザイナーがデザインを実現するための技術もそうそう思いつかない。ボーダーに画像を使いたいと言われた時、エンジニアがそのような機能はないのでできない、と言ってしまう可能性もある。今回やっていることはどちらかというとデザイナー主体のことで、デザイナーがそれを実現するための技術的知識があるか?というところが問われる。

このようなデザインは非常に個人サイト的で、商業サイトではトレンドもあるためこのようなデザインを採用することはない。というよりも今は非常にDHTML流行りなので、そもそもアクセシビリティ自体がナンセンスのように言われることも少なくないし、こうした指向がないために見かけないのかもしれないが、アクセシビリティとデザインを両立し、独自性があり、かつ習慣に基づくなじみやすさを満たす、というこうした技法は、そうしたサイトをみないだけに抜け落ちるポイントになっているのではないか?と思う。

今回は他の方法もあるにはあるのだが、これが最もアクセシビリティが高い方法だと思う。個人的には、最新のウェブブラウザでなければ見られないようなサイトは好きでない。

なお、現状公開しているサイトはこの仕様になっていない。現在テンプレートを修正したところだからだ。恐らく、本体ウェブサイトではなく、商業ページのほうが先にこのレイアウトを採用するだろう。現在の本体ウェブサイトは類似のデザインを採用しているが、バグがある。


/* Skin CSS for general essay.
* This is used by essays independent from the site.
*/

/* Top definition */
body {
background: #fff url("//reasonset.net/img/wp/heartline.gif") repeat-y 15% 0% scroll;
font-size: 10pt;
color: #39f;

}


/* Main Container. Over all container. */
#MainContainer {
width : 950;
margin : 0 auto;
background: #e0f0ff url("//reasonset.net/img/wp/check_bp.png") repeat scroll;
font-family: "Rounded-X M+ 2c","Migu 1C","M+IPA+2VM circle","Gen Jyuu Gothic Normal","VL P Gothic", "Hiragino Maru Gothic", "Meiryo",sans-serif; /* define Japanese Font */
position: relative;
padding: 45px;
}

/* For overwrite font-family for English document. */
#MainContainer {

font-family: serif;

}

/* Top banner */
#TopBan {
margin : 0px 0px 18px 0px;
font-size: 300%;
padding: 1.3em;
position: relative;
}

#UnderContainer {
position: relative;
}

/* Main content container */
#LeftPage {
position: relative;
top: 0px;
left: 0px;
z-index: 1000;
/*   margin: 30px; */
padding: 0;
background-color: transparent;
/*   border: blue 1px solid; */
width: 650px;
}

#SideBar {
padding: 0;
/*   border: blue 1px solid; */
position: absolute;
right: 0px;
top: 0px;
width: 250px;
z-index: 200;
}

/* Any container. */
.container {
background-color: #fff;
padding : 4em;
/*   border: red 1px solid; */
margin: 0;

}

/* paragraph */
p:first-letter {
text-indent: 1em;
}

p {
line-height: 1.2;
letter-spacing: 0.25em;
}

/* headline to left */
h1,h2,h3,h4,h5,h6 { text-indent: -1.3em; }



<html>
<head>
<link rel="stylesheet" type="text/css" href="./puredoc.css" />
<link rel="stylesheet" type="text/css" href="./puredoc_skin.css" />
<link rel="stylesheet" type="text/css" href="./gen-essay-skin.css" />

</head>
<body>
<div id="MainContainer">

<div id="TopBan" class="container">
Site title.
</div>
<div id="UnderContainer">

<div id="SideBar">
<div class="container">Sometext</div>
</div>
<div id="LeftPage">
<div class="container">
<h1>H1 title</h1>
<h2>h2 title</h2>
<p> p1</p>
<p>p2</p>
</div>

</div>
</div>
</div>



</body>
</html>

DeleGateでHTTPSリバースプロキシ

私のサイトはずっとhttpsで接続できなかったのだけれど、ようやく手を入れることにした。

HTTPSによる接続自体はできるのでサーバーは動いているし、ファイアウォールも阻害していない。証明書関連の問題だと判断できる。

DeleGate + SSLについての情報は大概が古く、SSLwayについてしか言及されていない。DeleGateの最新マニュアルを見ると、STLSというビルトインTLSフィルタを持ち、またビルトイン匿名証明書を持つため証明書も不要であるように思える。ではどう使うのか??

jfuruyaのブログに答があった。DelegateのパラメータとしてSTLS=”fcl,fsv:https”を渡す必要があるのだ。しかしこれだとHTTPでアクセスするとはじかれる。ちなみに、SERVER=httpではhttpsで接続しろと言われる。マニュアルを確認、どうもSTLS=”-fcl,-fsv:https”であるべきであるということが分かった。

しかしそのままでいくとスタイルシートが表示されない。どうやら、httpsでページを表示しているのにhttpでスタイルシートをロードしているのが問題らしい。つまり、リンクはhref=”http://…”ではなく、一般には説明されない書式でスキームを維持するhref=”//…”形式にしなくてはいけないようだ。

とりあえずこのような特殊な接続をする人はいないと思うので、全体は修正していないが、ビルド時にテンプレートを変更するので、サイト全体をビルドする時には直る、はずである。

Microsoft迷走中?

windows 10が発表された。Windows 8から9をとばして10にしたらしい。

おもなトピックスは、スタートメニューの復活、タイルをスタートメニューに統合、UIの統一をやめた、恐ろしく原始的だったコマンドプロンプトを多少改善した、というあたりだ。

だが、このちぐはぐ感がすごい。まず、タイルを使うタブレットスタイルがこれからの標準であり、これからはタッチデバイスの時代だとしてWindows8は従来型のUIを切り捨て、今後フェードアウトさせていくことを示した。今回はタイルやWindows StoreといったWindows 8で導入されたフィーチャーの主従関係が逆転しており、Windows 8で打ち出した価値観の誤りを認識し、軌道修正した形だろう。

Windows 8の使いにくさは尋常でないのでそれは正しいと歓迎するとする。しかし、タイルというのは、全面に機能を大きく表示するからタッチ端末にとって有意なのであり、スタートメニューの中に組み込んでも表示にスタートメニューをおさねばならないのではありがたみが全くない。ウィジットの代わりをさせようという部分もあったはずだが、内容をみるにはスタートメニューを開いたまま操作できないのではやはり意味がない。Windows 8の失敗をばっさり切るのではなく、中途半端にそれっぽく残した結果、ものすごくちぐはぐなものができあがっている。

そもそもタイルはシングルウィンドウを前提とした構造であり、全画面表示を標準とするなどシングルウィンドウ設計を推し進めてきたWindowsだが、マルチウィンドウ型の能率的インターフェイス(シングルウィンドウはいわば簡便型といえる)に戻すのであれば、わざわざスタートメニューを開いてまでタイルを欲するということはない、ということになぜ気がつかないのだろう?

また、WPSに続いてコマンドプロンプトの強化でパワーユーザーに応える、ということなのかもしれない。けれど、それが尋常じゃなく貧弱なものを非常識な程度に貧弱にしたというもので、あまりにも謎の改修だ。見捨てているのでなければいちから作り直して然るべきしろものなのにだ。

どこからどう見ても「これは使いにくそうだ!」としか思わないWindows 10。Windows Vistaあたりから「UIがちょっと不自由すぎないか」という感じになっていたが(内部的にはWindows XPはひどかったので、もちろんその意味では歓迎すべきところなのだが)、Windows 8から「見方によってはよくなった」要素を見出せなくなっている。パソコン離れはどう考えてもWindowsが使いにくい、という理由がかなりの部分を占めるように思えてならない。実際、AndroidもそのUIは相当に使いにくいと思うが、Windowsと比べたらだいぶマシだ。

また、「モバイルファースト、クラウドファースト」というスローガンをみると、Windows 8で示したタッチデバイス重視の設計を推し進めたかのように見える。だが、実際はそこに特化した設計には見えない、というよりもむしろ「どのデバイスでも扱いにくいようにした」ようにしか見えない。UIの統一をやめたのだから、モバイルデバイスならば従来のタイルUIを使う、ということだろうか?もしそうだとしたら、「Windows 8が不評だったからとりあえず前っぽくしとくね」という極めて雑なやり方に見える。そもそも、モバイルやクラウドが万能でないこと、わざわざPCを使うユーザーはもっとパワフルな環境を求めていることが理解できないあたりが、Microsoftは一体何をみているのだろう?と思う。

これであればLinuxデスクトップの使いやすさ、なじみやすさ、能率は圧倒的なものがあると思うのだが、やはり一般の人が触れることがあまりにないこと、導入部分の困難さ、情報の雑さや風潮などが邪魔をするのだろう。機能的なLinuxの圧倒的優位が反映されないのはなんとももどかしい。というよりも、Microsoftに、独占的地位における責任(パワーユーザーやデスクトップユーザーを切り捨てて強制的にコモディティ化を進めることの誤り)を理解させるためにも、LinuxがWindowsを明確に侵食する状況は起こるべきであると思う。

Microsoftはまた、Internet Explorerを改名する計画であるという。そもそもInternet Explorerが不人気なのは、標準に準拠しておらず開発側に余計な負担ばかりを強いて低機能であることや、ユーザーからみてもそのことがもたらすレンダリングの不備、機能の不完全性なのであり、私のもとにこのブログが以前のテーマではIEで見られないという意見が寄せられた。その実態のダメさを覆い隠すために「改名してごまかそう」というのは、Microsoftは一体何を見ているのかと思う。もはやまっとうな製品を作る力がないのだろうか?

Linuxで最新のFlash player pluginを使う

LinuxのFlash PlayerはAdobeがサポートを終了し、11.2が最終バージョンになっている。もうだいぶ古くなって、最近は様々なサイトで動画が見られないなどの不具合がでている。いや、動画のようなコンテンツだけならいい。保険サイトのようなところが見られない、という事態すらある。

Flash PlayerはGoogleのメンテナンスに移行し、案の定、Googleが抱え込んでChromeに同梱している。そう、Flash Player単体のリリースはしていないのだ。当然ながら、Chromiumや、その派生であるSRWare ironにはFLash Player pluginが含まれていない。

MozillaはChromeが利用するPepperプラグインには「興味がない」と言っているため、このままいくとFirefoxでFlash Playerは利用できなくなる。既に11.2までしか利用できずに様々なサイトが見られなくなってきている。だが、chromiumやironはPepperプラグインが利用できるため、術はある。

どうしてもGoogle Chromeが受け入れられなかったため、Chrome x84_64 rpmをダウンロードし、それをarkでPepperFlashのみ展開。あとは

iron --ppapi-flash-path=/opt/google/chrome/PepperFlash/libpepflashplayer.so --ppapi-flash-version=15.0.0.152

のようにすればよい。バージョンはmanifest.jsonファイルを参照する。

のだが、これでうまくいかずに随分悩んでしまった。理由は、自分で書いたiron起動用スクリプトが引数を渡すようになっていなかった、という実にくだらない理由。スクリプトを書き換え、デフォルトでプラグインをロードするようにするとともに引数を渡すようにした。