reborn: akahukuplus

この一ヶ月特に何も作っていなかったというのはつまり、引っ越ししたのでそもそもネットから遮断されていたということなのだが、その直前までは何をしていたのかといえば、wasavi に関してはほとんどコードをいじっていない。

いじっていたのは赤福プラスとよばれるブラウザ用拡張なのである。

かつてふたば☆ちゃんねる向けに IE のコンテキストメニューを拡張する赤福というツールを作った。赤福プラスはその Opera 版というわけだ。Opera 版は当時の Opera が搭載したばかりのユーザースクリプトの仕組に乗っかって動作し、コンテキストメニューにとどまらない様々な機能を持っていた。

その後、Chrome でも動くようにしたり、その過程でブラウザ拡張として構成しなおしたりしたのだが、さすがに建て増し続きだったし、また IE6 あたりでも動作するようにしていたので、例えば Selector API とか XPath とか続々とブラウザに搭載されていく新機能を使うわけにも行かず、中味はなかなかぐぬぬなコードになっていた。

今回、そんなわけで一から作り直してみようということである。残念ながら IE はサポート外となる。最近の IE 自身は、新しい赤福プラスを動作させるポテンシャルは十分あるのだけど、スクリプトベースの拡張の仕組みがないので。一方で、Presto Opera はサポートする。サポートするも何も、Opera 12 で開発してるので、未だにファーストクラスのブラウザだったりする。この他には Chrome と Blink Opera でテストする。気が向けば Firefox 版も作るかもしれない(気が向かないのは、Firefox には別の人が作った赤福がすでにあるからである)。

技術的な面に目を向けてみると、フロントエンドとバックエンドで全く違ういくつかのトピックがある。

まずフロントエンドからだが、赤福プラスというのはつまりふたばの画像掲示板の html を動的にちょっと書き換えるツールだ。ここではふたばの画像掲示板に DOMContentLoaded でスクリプトを引っ掛けて、ページの DOM をごにょごにょするのがフロントエンドの役割だ。

しかし、ふたばの画像掲示板が吐く html というのは、まああんまりそういう再利用はしやすくないのである。そこで、おそらく他のふたば用ツールはほとんどやっていないであろう手法を取る。ページを読み込んだらそれをスクレイピングし、一旦中間的な xml を構築する。さらにそれを XSLT プロセッサに与えて html に変換するのである。続きのレスを読んだりダイアログを出したりするときも必要なら XSL による変換が入るので、けっこう XSLT が大回転することになる。

これによってふたばの元々の html に振り回されるのはスクレイピング処理部だけになり、その他の部分は自分で完全に制御できる xml だけを見ればよくなる。また、ページ全体を制御できるのでよりダイナミックにページを構成することが可能になる。たとえばスティッキーなサムネイルとかバナー、固定ヘッダなどをなんでも導入できるようになる。

次にバックエンド。バックエンドとはつまり拡張の表に出てこない裏方の部分だが、実はこれは wasavi とちょっと関連する。wasavi もバックエンドを持っている。wasavi もまたいくつかのブラウザで動くため、各ブラウザの拡張の仕組みをある程度抽象化させた部分をもっているのだが、残念ながら完全ではなかった。また、wasavi というアプリケーションからも独立してるわけでもなかった。

これがずっと気にかかっていたので、今回を機にブラウザ拡張の抽象化層をきっちり作り、またアプリケーションからも完全に独立させたい。その抽象化層をベースにして赤福プラスのバックエンドを構築し、さらに wasavi にもバックポートする。なかなか遠大・壮大な計画なのである。

バックエンドに関してはもうひとつやることがある。オンラインストレージをアプリケーションから利用する際の承認において、dropbox はなんかなかなか OAuth 2.0 をサポートしなかった。ので、wasavi も jsOAuth というちょっと癖のあるライブラリを使って OAuth 1.0 で繋ぐしかなかったのである。しかし最近なのか結構前なのか知らないけど、いつの間にか OAuth 2.0 がサポートされていたのでそのへんの仕組みをごっそり書き直したい。当然この辺りも wasavi にバックポートされることになる。

赤福プラスにおいては、オンラインストレージは画像の保存・スレッドの保存時に利用することになる。画像のサムネイルから保存ボタンを押すとオンラインストレージの API を通して保存を行うのである。オンラインストレージ側の機能でローカルや複数デバイス間で同期することができる。

最近の状況はこんな感じです。

serif or sans-serif

文字の形は一般的に書体、フォント、タイプフェイスなどとよばれる。

欧文の場合、まず大きく分けて serif 体と sans-serif 体(と、その他)がある。見た目上の決定的な違いは、前者がいわゆるヒゲ付きで、後者がヒゲなしだということなのだが、1 文字 1 文字の見た目以上の違いがもっといろいろなところに現れる。

書籍などの印刷物なんかでは、だいたい本文のような長い段落の文章は serif で組む。serif のほうが読みやすいからである。対して、見出しのように目立ってなんぼの部分は sans-serif で組む。そのほうが目立つからである。とこのように、それぞれのデザインに用途の向き不向きがある。したがって普通は適材適所にそれぞれの特徴を活かした組版を行う。

翻ってコンピュータ上でのテキストの組版、とりわけ web ページのそれはどうなのかというと、残念ながら長い文章であっても serif が使われることは少ないように思える。特に日本語のページではそうである。これは一つ理由が考えられて、現在の一般的なディスプレイのピクセル密度では、serif 体はあんまり綺麗に表現できないのである。

個人的には、ディスプレイ上であっても長い文章は serif で読みたい。日本語の書体では serif / sans-serif は明朝体 / ゴシック体というものに対応する。しかしどうもゴシック体で組まれた文章は、クールでポップでかっこよくはあるのだけど、なんというか真摯さに欠ける。どんな高尚な内容の文章も、メイリオとかヒラギノ角でレンダリングしてしまうと、薄っぺらな C 調言葉にしか見えなくなってしまうのである。これは「おまえは何を言っているんだ」と言われそうだが、かなり本気でそう思っている。そんなわけで、もっと明朝体をゴリ押ししたい。ゴリ押ししていきたい。どうでもいいけど C 調とか我ながら発想が古いなあ。

さて、最近は特にモバイル機器を先頭に、ディスプレイの解像度はじわじわと上がりつつある。96ppi どころか、一気に 200 とか 300 とかの ppi に達しているものもある。これくらいの解像度があれば十分 serif も明朝体も綺麗に表示できる。ヘタしたら、アンチエイリアシングのような小細工すら必要ないかもしれない。この分だと、あと数年もすればほとんどのディスプレイが高解像度に置き換わるのではないか。そうするとつまり、ハードウェアの面では明朝体ゴリ押し計画に対する障壁はないことになる。

問題はソフトウェアの面なのである。

RDP 8.0 #2

いろいろ試してみると、[cci]ping[/cci] では効果がなかった。また、Windows7 ではローカルセキュリティポリシーの設定によって RDP 8.x かそれ未満を使うかを指定できるのだが、8.x を指定しなければ勝手にスリープは起こらなかった。やはり 8.x に問題があるようだ。

これはうちだけではなく普遍的な問題なのか、Windows7 向けの更新プログラムが現在は公開中断されているようだ。なんということでしょう。

MS さん早く直してください。

RDP 8.0

最近 Windows7 にもたらされた更新の中に、RDP、つまりリモートデスクトップで使用するプロトコルのバージョンを 8.0 に上げるというものがある。これは 7.1 に比べてデータの送信がずいぶん軽くなっているという触れ込みである。そいつは嬉しいじゃないか、ということでいれてみた。

確かに体感的に軽くなっているような気がしないでもない。などと書くと曖昧だけど、いや実際リモートで地デジなんかを見ると、従来はその時々の状態によってはコマ送りになったり音声がノイズまみれになったりすることもあったのがかなり軽減されたりしているので、実際効率は上がっているのだと思う。いいことだ。

しかしいいことばかりではないのだった。

ホスト側は 30 分、インタラクティブな操作を行わないと自動的にスリープするようにしているのである。従来は、その設定の状態でリモートデスクトップに接続した場合でも、それを通したリモート側の操作がホストのスリープを回避するアクションとして認識されていた。しかし RDP を 8.0 にすると無効になってしまう感じなのだ。リモートデスクトップを操作中に予告なく画面が固まり、あれ? ハングした? と思うとホストが眠りに入っている。なにこれもうやめてよね!

とりあえず、RDP 以外の手段でホストに定期的にちょっかいを出せば回避できる。たとえば WMP でホスト上のメディアファイルをずっと再生し続けるとか、あるいは単に [cci]ping -t[/cci] するとか。

MS さん早く直してください。

creating NTFS native symbolic link in cygwin

以前 cygwin 上で、Windows Vista 以降の NTFS ネイティブなシンボリックリンクを作るために逡巡したことがあって、一応できたのだが、それは諸々の環境を整えた上で最終的には [cci]cmd /c mklink[/cci] を呼ぶというものであった。

これだとメッセージが mklink のそれになってしまうし、コードページの不整合が起きる(つまり UTF-8 な端末で呼ぶとメッセージが文字化けする)というどうでもいいけどどうでもよくない不都合もある。それを置いても、やはり cygwin の中からコマンドプロンプトベースの実行ファイルを呼び出すのはなんともイケてない。なんとかならないか。

さて Windows 側のシステム環境変数 [cci]CYGWIN[/cci] に設定する値によって、cygwin の動作を制御することができるのだが(ドキュメント)、その中に winsymlinks という項目がある。これを [cci]nativestrict[/cci] という値にすることによって解決できた。ちなみにこの項目は [cci]lnk[/cci]、[cci]native[/cci]、[cci]nativestrict[/cci] の 3 つの値を割り当てることができるのだが、

  • lnk: シンボリックリンクとして Explorer が認識する .lnk ファイルを作成する
  • native: シンボリックリンクとして NTFS ネイティブなそれを作成する。作成が不可能な場合(NTFS じゃないとか、権限がないとか)は、lnk として振る舞う
  • nativestrict: native と同様に ネイティブなシンボリックリンクを作成するが、作成が不可能な場合はエラーを返す

というわけで、ナウい cygwin で NTFS ネイティブなシンボリックを作成するには

  1. Administrators グループに属する別のアカウントを作成する
  2. 普段使用するアカウントを Administrators グループから外し、Users に含めるようにする(これにより、UAC ダイアログでは単なる権限のエスカレーションの確認だけでなく、管理者アカウントのパスワードを入力を求められるようになるが、慣れるしかない)
  3. ローカルセキュリティポリシーを起動し、[cci]セキュリティの設定 -> ローカルポリシー -> ユーザー権利の割り当て[/cci] の中にある [cci]シンボリック リンクの作成[/cci] に普段使用するアカウント名を追加する
  4. システム環境変数 [cci]CYGWIN[/cci] に [cci]winsymlinks:nativestrict[/cci] を追加する

という手順になる。

hang on search?

issue #20 で、検索するとパターンによって無限ループになってタブを閉じるしかなくなるというのがある。特に [cci]|[/cci] とかが危険らしい。なるほどなかなかそんな雰囲気がしないでもない。

これは由々しき問題だ……ということですぐ直そうとしてみたのだけど、再現しない。ということでどういうパターンだと発生するのか聞いているところ。

home updated

wasavi のホームを更新してみたりした。といっても開発版のエクステンションは github に置くようにしたし、フォーラムのようなものは全然利用されないので除去した、つまり単に readme.md を表示するだけの特に存在理由のないページになっている。

まあきっといろいろと、そのうちに拡充していくんじゃないかな!(希望的観測)

visual in vi #8

vim 同様、V を押すことで行単位の選択もできるようにした。モード名は bound_line。また、bound モード中に bound_line モードに入ると(あるいは逆に bound_line から bound でも)、現在の選択範囲を活かしたまま文字単位・行単位が切り替わるようにした。これも vim と同様。

ところで vi では、空行以外の行においてカーソルを改行の上に置くことはできない。vim もこれは同じだが、ただし visual 系モードに入るとその制限が取り払われる。これはこれでまあそういうものなのかな、ということで一応付けてみたのだが……これ、もしかしてなくてもよくなくなくない? とりあえずオミットしておこう。クレームが付いたらつける。

それにしてもかなり wasavi.js に手が入った。とりあえずの機能は実装し終えたのでモードを切り替えてテスト三昧の毎日になるのである。

visual in vi #7

vim の visual モード中に実行できる編集コマンドのうち、大文字のものはほぼ、操作対象が行単位になる。行単位ということは、選択範囲の端点の桁位置は使用されないということだ。行位置だけが意味を持つ。

行単位の操作においては、特に削除処理について文字単位でのそれとの違いを意識する必要がある。具体的には行にマークが含まれる場合である。マークを含んだ行を文字単位で全削除(つまり [cci]^.*$[/cci] を削除)したとしても、マークは空行の先頭位置に収斂され、削除されない。一方、行単位での削除(つまり [cci]^.*\n[/cci])の場合はマークごと削除される。これは決定的な違いだ。ちなみに削除に対応する undo 情報にはマークも含まれるので、undo すれば行全体とともにマークも復活する。

ところで、最後に使用した選択範囲はマーク [cci]<[/cci] と [cci]>[/cci] で参照することができる。では、visual モードを経由して行単位での削除を行った場合、それらのマークはどうなるのか? というと vim では削除後もそれらのマークは生き残っているのである。もちろん本来の選択範囲は削除されているので、全然関係ない別の行を指していることになる。これはなんというかバグなのか仕様なのか判別しづらい。

wasavi では行単位で削除を行ったあとは [cci]<[/cci] と [cci]>[/cci] マークは無効になるようにした。