Comparators―比べてみればわかること

第1回 Hackability vs. Hackiness

この記事を読むのに必要な時間:およそ 4 分

今回からしばらく「Comparators」と題した読み物を書かせてもらうことになりました。よく似た,あるいは相反する2つのアイデアを見比べたら何かが見えてこないか。そんなもくろみで書きたいと思っています。

今回のComparator(比較演算子)はこの2つ,HackabilityとHackinessです図1)⁠どちらも耳慣れない言葉かもしれません。

図1 今回のComparator

図1 今回のComparator

Hackability

Hackabilityとは,ソフトウェアやシステムの性質,その対象が「ハックできること」「ハックしやすいこと」を意味します。ハックと言ってもセキュリティホールを攻撃するほうではなく,コードを書いて遊ぶほうです。

「あの会社から出てきた新しいサービス,スクリーンキャストを見たよ。デザインはカッコいいね。けっこう遊べそう?」⁠いやー,SDKどころかAPIもないからHackabilityはいまいちですね。ページもJavaScriptが多くてスクレイピングに一苦労でしたよ」なんて風に使います。

Hackiness

対するHackinessは形容詞Hackyを名詞化したもので,これもソフトウェアの性質を表す言葉です。コードやソフトウェアが「まるっきりハック」であること,やっつけ仕事なコードを評するときに使います。

「あの仕事やっておきましたよー。とりあえず動いています」⁠おっ!早いね……ってこれすげえHackyじゃん。なんですかこの山のように差し込まれたif文は。こっちはサードパーティのライブラリに手を入れちゃってるし。このパラメータを変えて再起動すると……。ああ,やっぱりエラー。動くのはわかったから,あとはちゃんと整理しないとね」

WebのHackability

話をHackabilityに戻しましょう。Hackabilityを持つシステムの代表例はWebです。Webの基盤技術はHackabilityの高いデザインに従っています。

まずプロトコルやデータが単純なテキストであるため,簡単に中身を覗くことができます。プロトコルの詳しい知識なしに見よう見まねでHTMLやHTTPを読み書きした経験は,誰にでもあるのではないでしょうか。バイナリ形式のデータ相手にこうはいきません。

WebブラウザもWebのHackabilityを手助けしています。たとえばメニューからは「ページのソースを表示」できます。表示したページに対しデバッガを起動するのも簡単です。ユーザが簡単にデバッグできるアプリケーションなんて,ほかにどれだけあるでしょうか。Webの外ではデバッガすらなかなかすぐには使えません。しかしWebでは開発者が何もしなくてもブラウザが勝手にWebアプリケーションをHackableにしてしまいます。むしろアプリケーションをHackableでなくするほうが一苦労です。

Webが分散システムである点もHackabilityを支えています。WebブラウザとWebサーバは別のプロセスとして動いていますから,プログラム同士は必ず通信をします。そしてブラウザとサーバの通信を横取りしたり,サーバ相手にブラウザのフリをするのはとても簡単です。

読み書きしやすいテキスト形式,割り込みやすい分散アーキテクチャ,デバッガの遍在。そのほかにも標準化され互換性を重んじるAPIなど,さまざまな性質がWebのHackabilityを支えています。

プラットフォームとHackability

WebのHackabilityは偶然の産物ではありません。黎明期(れいめいき)⁠Webの設計者たちは,ハイパーテキストのアイデアに魅力を感じた人々に互換性のあるソフトウェアを作ってほしいと願いました。これはインターネットがネットワークソフトウェアにもたらしたHackabilityを,インターネットの上で動くアプリケーションに持ち込もうとする大きな流れの一部でもありました。

Webやインターネットのように,振る舞いを公開してプログラム可能にしたシステムやソフトウェアをプラットフォームと呼びます。プラットフォームという言葉はさまざまな意味で使われはじめていますが,ここではほかのソフトウェアに向けて振る舞いを明らかにしているもの,具体的にはプロトコルやAPIを公開したソフトウェアのことを指すものとして話を進めましょう。WindowsやLinuxのようなOSや,Facebookのような一部のWeb上のサービスなどがプラットフォームとしてよく知られています。

Hackabilityの程度

プラットフォームにはHackabilityがあります。私たち開発者のコードからAPIを通じて呼び出すことができるからです。とはいえ,世の中のプラットフォームがどれも等しくHackableであると言えるのでしょうか。明らかにそんなことはありません。

プラットフォームが開発者にアクセスを許している情報や機能は,APIによって制限されています。たとえばAPIがすべてのデータにアクセスできるWeb上のサービスはほとんどありません。たとえ同じ分野のサービスでも,APIで公開されているデータの範囲はさまざまです。たとえばOSで考えてみると,デスクトップOSの多くは開発者がカーネルモジュールやドライバを書くことができました。でもスマートフォン向けOSでそれを許しているものは限られています。

WebのサービスやOSなど,同じ分野に属するプラットフォーム同士を比べればHackabilityの個体差は明らかです。つまりHackabilityは白黒はっきりした真偽値ではなく,濃淡のある連続した概念,程度の問題なのです。プラットフォームのHackabilityは機能やデータという軸の上に分布しています。アクセスできるデータや機能が多いほどHackabilityは高くなります。これらさまざまなプラットフォームと比べてみると,Webというプラットフォームに備わったHackabilityの高さに改めて気づくのではないでしょうか。

オープンソースのHackability

オープンソースライセンスは,コードやデザインではなくライセンスによってソフトウェアのHackabilityを実現しました。オープンソースのソフトウェアはほとんど定義からHackableです。ソースコードが公開され改変が認められている以上,私たちがそれをどうハックしようが自由なわけですから。

では,オープンソースのソフトウェアはどれも等しくHackableなのでしょうか。それとも濃淡があるのでしょうか。たとえばEclipseとLinuxとjQuery Mobileが同じくらいハックしやすいものか想像してみましょう。……とてもそうは思えませんよね。一方で,プラットフォームのHackabilityを議論するときに使った評価軸,具体的には機能やデータへのアクセス度合いを持ち出すのもどこかピントがずれています。

プラットフォームのHackabilityに向けた視線は,プラットフォームの上で書くコードの遊びやすさや自由度を気にしていました。一方オープンソースのHackabilityを評価するとき気になるのは,ソフトウェアそれ自体,コードの中でのやりやすさです。気にしていることが違いますから,同じようには比べられません。

著者プロフィール

森田創(もりたはじめ)

平日はWebブラウザの開発,休日はWebブラウザの利用に従事。最近の趣味は/etc/hostsファイルに中毒性の高いWebサイトをリストし,127.0.0.1にリダイレクトすること。現在7サイト。スマートフォンの勉強をしなければと思いつつ/etc/hostsにアクセスできない端末を持つのが不安で躊躇している。

http://steps.dodgson.org/

コメント

コメントの記入