芝村裕吏『宇宙人相場』。オチはよい

芝村裕吏『宇宙人相場』

一部にコアなファンのいる芝村裕吏の早川のSF3本目。

子供の頃からずっとオタクでその業界で頑張ってきた結果、35歳にして小さなアニメ関連グッズ会社の社長をやっていた主人公が、でもそろそろ結婚したいなと思っていた矢先にふと出会った病気がちな女性と結婚することになり、だが病気がちな妻といっしょに過ごすために、義父の手ほどきを受けてデイトレーディング（スキャルピング）を始めることになるが、いっぽうなぜか質問ばかりしてくるスパムメールの主は自分が宇宙人だと主張をはじめ……

といったあらすじ。意味わからんと思ったかもしれませんがわりと適正なあらすじかと思います。オタク、デイトレーディング、宇宙人ファーストコンタクトというだいぶ無理な組み合わせの三題噺といった風情。ただ、この三要素は作中でうまく絡み合っているとは思えず、またそれぞれの書き込みというか内容についても、ディープな向きからは不満も残るもののようす。

たとえば株についてみると、主人公がふつうに勝ちすぎという点がレビューなんかで指摘されている……ってまあそれはそういう話だと思って読むべきかなと思ったし、「オタクであればあるほど現実と虚構の区別はつく」という作中の主人公の述懐を引くまでもなく、こんなの読んで株やろうという阿呆はおらんと思うので別に良いのでは、とは思うけれど。それに主人公も失敗して死にそうになったりしてるし。

ただ言い方を変えると、いわゆる経済小説としての完成度はべつに高くない。素人がいきなりはじめて大儲けしました、反射神経と判断力が鍵なのですが頑張りました、という話なので、だからなにっていう感じはある。

オタク方面については個人的にもにょるところがあって、主人公がコミュニケーション能力の薄いオタクだということがあって、いささか身につまされる面もある一方、主人公が嫁とトレーディングにのめり込んでいくうちにアニメとかどうでもよくなってくるのを見るのは悲しい気分になってくる（降って湧いたように嫁が登場する展開だからか、願望充足的という指摘も見た気がするけれど、ふつうのオタクの願望充足はこういうものではないでしょう）。後半の主人公はほとんど嫁かわいいに終始しており（あとは嫁の実家の問題に気に病むぐらいであり）、アニオタというアイデンティティはこの小説に必要なのか？というのは疑問を抱かざるをえない面はある。まあ結婚してオタクをやめるってのは、ある意味リアルだとは思うけれど……（そういう意味でエピローグでの元社員の反応なんかはリアルに思える）。

ただオタクを描く芝村の手つきは非常に手慣れており、主人公のオタクらしい言動や考え方や周囲との噛みあわなさというのは読んでいて楽しく、この作品を豊かにしているとも思える。

まあさっくり読めて総合的にはよろしいんじゃないでしょうか。ただ宇宙人、どうなの、この話にいるの、ってのはよくわからんですね……。

---

と思ったけど最後の宇宙人のセリフで設定が明らかになるわけですね。最初すごい雑に読み飛ばしてしまったが、ああなるほどね、ってなる。

きちんと伏線を張って回収するのが良い向きにはあまり好まれないかもしれませんが、あんまり溜めずに、さりげなく一言で世界をひっくりかえすというのは、個人的には好き。一種のギャフンオチですね。

tarを解凍しつつキャッシュに展開するService worker

というのを書いてみました。なんかたくさんアセットのある例、ってことで emojify.js という絵文字系のJSライブラリのデモページを使ってます。

https://googledrive.com/host/0B8b5YMw-yJleQ3N4bkxrNVlfYjA/

このページはemojify.jsのデモページである http://hassankhan.github.io/emojify.js/ とほとんど同じです。タイトルと注意書きと、service workersの登録を除けば。

ただ、もとのデモページと違って images ディレクトリを消してるので画像ロードが盛大に失敗します。画面スクロールするとサンプル絵文字が読み込み失敗になっていくのが見えるはずです。

ところがChrome 40以降であれば、この時点でservice workerが登録され、動き始めます。service workerは画像ファイルをアーカイブしたimages.tarを取得し、なかのファイルを取り出してキャッシュに突っ込みます。

なので、数秒待ってから（この処理が完了してから）リロードすると、さっきは読み込み失敗してた画像が突然表示されるようになります。しかもキャッシュから取ってくるので速い！という。

書いていて途中で「まあでもコネクションを減らす目的だったらpipeliningしたりspdy使ったりしたほうが効率いいよな……」とふと我に返るタイミングもありましたが、あまり気にしないことに。

---

tarってしょせんヘッダとコンテントが並んでるだけのデータ構造でしょ、って思ってて、詳細しらんけどそれぐらいJSでも読めるんじゃないかなぁ、ということで思いついたのがこのデモのきっかけです。tarのパーサはGNUのマニュアルを見ながら超適当に書きました。

tarは512バイトごとのブロック単位になっており、512バイトのヘッダブロックにそのファイルのメタデータを記述し、必要ならそのファイルのコンテンツを保持したブロックが続きます（ディレクトリやシンボリックリンクなどはコンテントは存在しないのでいきなり次のブロックが続く）。

ファイルの終端は0クリアされたブロックが2つ続くとか、フォーマットやチェックサムの項目があるとか、そういう細々したのがいろいろあるのですが、今回はそういうのは完璧に無視し、ファイル名とファイル長だけを取ってくる単純な仕様にしました。ArrayBufferを使って512バイトごとに区切り、特定のオフセットにアクセスするだけなので簡単でした。

ちょっと驚いたのはサイズのフィールドはASCIIの数字で8進数表記ということですかね。なんでそんな仕様なんでしょうか。

ウィリアム・ソウルゼンバーグ『ねずみに支配された島』

ウィリアム・ソウルゼンバーグ『ネズミに支配された島』

面白かったけれど、『捕食者なき世界』ほどの面白さはないかな、と思いました。著者のソウルゼンバーグはこういった著書など生態系に関するテーマに強い科学ジャーナリスト。

本書の指摘は単純明快。ねずみに代表される害獣によって多くの固有種が絶滅の危機に瀕しています。害獣駆除の試みが始まって、いちおう成功を収めつつあります。以上。

著者も指摘するように、「野生動物の絶滅」とかというと、多くの人が思い浮かべるのは、毛皮や角などを求めて（多くは西洋文明の）人間によって根絶させられるというものかも。ですが、多くの絶滅は孤立した島の固有種に対して起こり、それは西洋文明とはあまり関係なく、人間の移住や、それにともなうねずみなどの害獣によって引き起こされると著者は書く。

主な舞台はニュージーランドとアリューシャン列島。ニュージーランドの飛べない鳥カカポやアリューシャン列島の海鳥たちはねずみによって絶滅の危機に瀕しているとされます。ねずみは空腹でなくても獲物を狩れるうちには狩ってしまう習性があり（過剰な分はためこんで腐らせてしまったりする）、そういう獲物が生態系に存在しなかった島では少数であってもおそるべき効果を発揮してしまうとか。あるところではネコが、またあるところではキツネが、ヒツジやブタが、生態系を崩壊させてしまう。

イースター島の文明崩壊、ヤシの木を刈りつくしてしまったのも、住民がみずからすべて伐採したというジャレド・ダイヤモンドの説（『文明崩壊』）よりも、住民が持ち込んだねずみにむしろ原因があることが示唆されるのだとか。

こういう問題への対抗策は、そういう外来種の害獣たちを一匹残らず駆除すること。駆除というのはつまり、ねずみの場合は毒を含んだ餌をばらまいて殺し尽くすこと。ねこなら罠や銃で狩り尽くすことを意味します。ですが多くが絶海の孤島であるこうした島において、駆除のプロジェクトは簡単なものではありません。ここにねずみ根絶に向けた一大プロジェクトが発足するわけですが……

---

著者はどちらかといえば野生動物の保全という目的に疑問を抱いていないけれども、個人的にはいささか割り切れない面もあります。野生動物というのはねずみがいなくても、勝手に滅んでいたものかもしれません。その地に適応してしまったねずみを殺すのは、ねずみがありふれた種であり、よそにいくらでもいるからですが、それは命の比較なのでは。ねずみを殺すにしても、もっと人道的な方法はないのだろうか……などなどの指摘は本書でも一応取り扱われています。ほかにも、複雑な因果関係がきちんと議論されないまま、動物を根絶させるという点から反対運動が起こるということもあるようで、ブタを根絶させようとして反対運動が起こった事例なども紹介されています。

また、毒餌によって根絶させるという場合、ねずみだけがターゲットになるともかぎりません。毒餌はほかにも効いてしまうでしょうし、ねずみの死骸を食べた野生動物が犠牲になるケースもあるのだとか。複雑な生態系の話なので、問題はそうそう簡単でもありません。

でも、そういった問題を抱えつつも、総合的にはいろんな問題が実際に解決されているのは事実であり、ともかくも先に進めていく、というのが本書の結末であり、ある種感動的ではあります。

個人的に前作より劣るかなと思ったのは、「害獣によって生態系が破壊される」というテーマが、『捕食者なき世界』のテーマほどの意外性がなく、予想よりはるかにすごいとはいえ「まあそうなんだろうな」というものであることと、毒餌のような対応策の単純さにあるのかもしれません。

ベン・ウィンタース『カウントダウンシティ』。『地上最後の刑事』の続編。わるくはないが……

ベン・ウィンタース『カウントダウンシティ』

『地上最後の刑事』の続編（→感想）。

『地上最後の刑事』では、小惑星の衝突による人類滅亡まであと半年という時期において、とある片田舎の街のふつうの刑事が事件を追う、という話だった。いわゆる破滅ものだけれど、あまり真剣にSFしてなくて、あくまでも警察小説としての体裁を保つことで、そこからかいま見える人類社会を描いているところがユニークで面白かった。

続編の本作は、衝突までもう3ヶ月を切ったある日。警察組織自体がほぼ崩壊していて退職した主人公が、知り合いの女性に頼られて失踪した夫を探す、という筋立て。

前巻の感想の最後に、続刊はつまらなくなるかも、という懸念を書いておいた。人類滅亡の日は決まっているけれどもそれはまだ半年先で、人によってはいろいろ好き勝手なことが始まっているけれども、社会は崩壊しきっていなくて、警察も士気は低いけれどもいちおう組織としては残っていて、みたいな奇妙なバランスが妙味だと思ったので、破滅が近づくとこのバランスが崩れちゃうっていう気もしたので。

この懸念はある程度あたっていた。滅亡までのカウントダウンは始まってしまい、社会はいろんなレベルで壊れている。食品配給制度が始まっていて、インフラは壊れ、電気や水道が使えなくなることもあり、主人公は警察をクビになっている。主人公が捜査の必要からあちこちに赴いた結果として、そういう社会の有り様が明らかになっていく小説手法は健在で、そこは面白かったのだけれど、前巻のような奇妙なバランスはもうない。これはほとんど破滅SFといってよく、そのわりに失踪者を探すという事件の「大したことなさ」はもうバランスが取れていない。それに最終的な事件の解決もあっさりしていて、なぜこの設定とこの展開にたいしてこんな事件なのか？というのが謎めいている。

前巻は士気の下がりきった警察組織のなかで何故か捜査を行う主人公というのがノワールっぽくなっている、という指摘があったけれど、その点で言うと今巻では主人公はもうクビになっているので、ある種「元警察の探偵」風味になっているところは面白くはある。でもまあそれは些事かな。

前巻でも奇妙に空虚だった主人公の捜査への動機はいっそう空白になり、一人称小説なのに主人公が何を考えて行動しているのか疑問と言わざるをえない話になっている……というのはまあ、主人公が実質的に狂言回しだからなのだけれど、そういう構成が読者にあからさまになってしまうのは残念感もある。

ここまで来たら最後まで読みたいところだし、個人的には面白く読んだけれど、まぁ前巻ほどではないかな。前巻を読んですごく気に入った自分みたいな人は読むべきですね。

マックス・バリー『Lexicon』。良質のエンタメ

Max Barry "Lexicon"

なんとなく原書で買ったが積んであったのをようやく読んだが面白かった。ページ・ターナーという言葉があるがまさにそういう感じの面白さ。

言葉によって人間の脳をハックして意のままに操る「説得」の能力を伝える秘密組織の「詩人」たち、という設定がまずイカしていて、とある理由により彼らの戦いに巻き込まれる一般人とおぼしき男のストーリーと、それと別にサンフランシスコで奇術をやっていた少女がスカウトされ、詩人としての訓練を積んでいく物語が交互に語られていく。この2つの物語がどう合流していくかは……まあすぐ予測はつくんだけど、それでも細部をうまく隠したまま物語をドライブさせていく手法は見事。

「言葉によって人を操る」といった設定やテーマは日本SFでも類例が多い気がするけれど、えてしてメタフィクショナルで衒学的にかっこつけてしまいがちということが観測されているように思う。本書はきっぱりとエンタメであって、そういう深みは一切ない……というとけなしているようだがそうではなくて、そこにあえて踏み入れなかったところがむしろエンタメ作家としてのマックス・バリーのえらいところなのではないかな、と思った。

「神経言語学」という単語を使って「言葉はただの音じゃない、言葉は意味を伝え、脳に特定の反応を引き起こす。ある言葉や音によって、この反応を誤作動させることができる」という設定、登場する「詩人」たちが実在の詩人の名前を借りたコードネームで名乗っているところなど、異能バトル漫画っぽい雰囲気すらある。結果としては「なんか呪文を唱えると相手を操れる」という微妙に安っぽい描写になっているところも含めて、まあよろしいのではないでしょうか、という気分。

楽しく読んだけれど、マックス・バリーはこれまでもそれなりに訳されているから、本書もやがて訳されることでしょう。がんばって英語で読む意味はあんまりないです。

web workers三兄弟

Service workersの仕様を説明していて思ったのだが人々はどれぐらいweb workersのことについて詳しいのだろうか。

あんがい知らない気がするので簡単に解説してみる。まあ俺もニワカです。

共通部分

ブラウザのなかで、ウェブページとはある程度独立して、ある種の処理をするためのスクリプトを実行するモノのことをworkerと呼んでいる。ようするにJSの実行環境というかVMインスタンスというか。

ブラウザのなかでふつうのJSの実行環境であるタブの中とはいろいろ違うが、

• windowオブジェクトがない。一部のJS APIは使えないしdocumentなどは持たない。DOMツリーもさわれない
• ただしメッセージループは持つ。windowはないがselfというやつがいてこいつを使う（self.onmessage = function() { ... } みたいな感じ）
• タブのなかとはmessage eventで通信する。postMessageというのを送ってmessageイベントをlistenする。JSオブジェクト（というかJSONというか）やArrayBufferは送れる

ええっと、こんだけか。

Workerは、ほかのプログラミング言語だとactorとか呼ばれるものに近い。実行環境は完全に分かれているので互いに隔離されている。共有データはないのでデータはコピーするしかない。所有権を譲渡する場合は参照だけ渡す最適化もあるけどそうなると手元からは読めなくなるし、まあそういう感じ。

ああっと補足をしておくと、Workerはみな起動時にスクリプトのURLを指定する。ふつうのプログラミング言語では、関数とかそういう単位を指定するとそいつが並行実行される気がするけれど、ファイルなのでそれより独立性が高く、グローバル変数も含めて環境は一切共有されない。共通の定数とかを使いたい場合、Workerには importScripts() という関数があってほかのJSファイルを読めるのでそういうのを使うことになる。

その場でスクリプトの生成をしたり特定の関数だけ呼びたい場合は、それを文字列化してBlobを作り、Blob URLを渡すというのが作法のようである。ただまあそれもWorkerならいいけどShared Workerではどうかなあ（Service workerは仕様上、Blob URLは使えない）。

Worker

簡単に言うとスレッドみたいなやつ。new Worker(scriptUrl)で作ると新しいworkerができる。元のスクリプトの実行環境とは隔離されていて非同期に動く。そんだけ。大元のタブが所有権を持っており、そいつが消えると自分も消える。

Web workerというと、このworkerのことを指すことが多い気がする（自分もそういうふうに使っていたこともある気がする）。一番の基本形。

Chrome / Firefox / Safari / Opera はかなり前からサポートしている。IEは10からっぽい。

Shared Worker

new SharedWorker(scriptUrl)でつくるやつ。Workerに似ているんだけど、同じURLに対してはひとつのインスタンスしか作られない。ふたつの違うタブから作ってもひとつのインスタンスで共有される。タブ間で通信したりデータ共有したりするのに使える。頑張ればタブ間でコネクションの一本化とかにも使えるだろう。

共有されているが、参照するやつがいなくなったら消滅する。タブを全部閉じたりとか。

タブ間通信とかチョー便利じゃんなんでみんな使わないの、Chromeとかバージョン4から使えるよ、と思ったらIEは未サポート、Safariは途中でサポートが消滅という悲しい目にあっている。可哀想な子……。

Service Worker

解説を書いた。navigator.serviceWorker.register(scriptUrl) で登録する。いっけんShared workerに似ているけれど、違いとしては、

• 登録元のタブと独立した生存期間を持つ。タブが閉じてても生きてることがある。
• フェッチなどオフライン処理に関係したイベントやAPIを持つ。したがってスクリプトの側からはオプショナルな機能として実現できる。

といったところ？　それにほかの面白機能のベースになるもよう。

先進的すぎてChromeでもまだ安定版では使えない、Firefoxもフラグに隠されている、ほかのブラウザはやる気があるのかどうかすら不明ですが、面白いと思ってる。

Chrome40にservice workersがきた

Chrome 40になってService workersが来たらしい。デモを動かしてみたり自分で書いてみたりして紹介記事でも書こうかなと思っていたが、 +Hajime Morrita はRebuild.fmに出演して紹介してしまったし、ほかにもすでにいくらか紹介記事が出始めてきた（たとえばhttp://qiita.com/kinu/items/2abd61b4390f9bbaffc9）。賑やかしにと自分もスクリーンキャストの動画も撮ってみた。

ここではデモの補足として、Service workersってどんなものなのかをふんわり考えてみる。

Service workers とは

って項目を書いたのだがこの説明が難しい……。新しいウェブのAPI、だけだとだからなにって感じ。Service workersはweb workersの一種なのだが、って説明しはじめると泥沼に嵌りそうだ。

Service workersでブラウザの機能として大きいと思うのは、タブと独立して動くJSの実行環境を手に入れるということだと思う。

Web workersというのはJSのスレッドみたいなものなので、普通にタブのなかのスクリプトから作られるし、タブが閉じられると消える。複数のタブで共有されるshared workerというのもいるけれど、これもタブが全部閉じたら消える。どちらもタブに従属している。

それと違い、Service workerはブラウザにインストールされる。さいしょにインストールするには、登録するページを読まないといけないけれど、登録が済んでしまえばページとは関係なく動作する（細かい補足になるが、動作するといっても、つねにプロセスを起動しっぱなしにするということではない。必要に応じて起動する）。で、ウェブページやウェブアプリと協調動作していろんなうれしい機能を提供する。

そういうバックグラウンドサービスというのは、実はこれまでブラウザにはなかった。拡張機能によってそういうのはなんとかしてきた歴史があったが、そうした無理を解消しつつ標準化していくのがService workersなのかなというのが個人的な認識だ。

Service workersの役目とスコープ

Service workerはウェブのリクエストを取り扱う。そういう意味では、少し前に話題になったフェッチAPIと関係がある。

リクエストの取扱範囲はスコープで制御される。デフォルトは登録元のサイトのトップで、これはようするにサイト全体がひとつのウェブアプリになっていてservice workerはそのウェブアプリに対して動作するということが念頭にあるのかなと思う。ただもちろん、登録時のオプショナル引数でそこからサブディレクトリに制限をかけることもできる。

取り扱い範囲のフェッチリクエストが来ると、まずService workersのfetchイベントハンドラを駆動する。Service workerはそのイベントハンドラを勝手に横取りして自分で勝手にレスポンスを作ってもよい（これがデモでやってみた事例）。なんにもしなければ普通のリクエストに戻っていく。

ただ、スクリーンキャストのなかでぶつぶつしゃべったように、ふつうはダミーデータを作ったりすることは少ないはずだ（ネットワークがつながってないときにエラーメッセージを渡すというのはあるかも）。ありがちなサンプルとしては、

• 画像やCSSなど静的なデータをキャッシュしておき、ネットワークなしでもページをロードできるようにする（オフライン化）
• twitterのフィードフェッチなど、複数タブを開いていると無駄になりそうなコネクションの一本化

といったところだろう。この辺はService worker専用のキャッシュAPIなどを使うことになる。と思う。

アプリのオフライン化についてはapplication cacheというAPIがこれまでもあったのだけど、残念ながらいろんな事情からマイナーな仕様にとどまっている。application cacheと比べると、簡単な事例についてはService workersのほうが書く量は増えることになるが、柔軟性が圧倒的に高く管理しやすいので、いろいろ考えるとService workersのほうがいいんじゃないかという気がする。application cacheのつらみはこの記事でよく解説されている（らしい。ごめん読んでない）。

Service workersとevent pages

Service workersの動作や仕様を眺めているとChrome拡張機能のevent pagesと近しい印象を受ける。

Chrome拡張機能にはいろんな機能があるんだけど、background pagesというのがあった。拡張機能はページにくっついたり、ポップアップになったり、自前でタブを開いたりするのだが、ユーザに見える部分とは別にいろんな処理をまとめるバックエンドがあるといろいろ便利で、それがbackground pagesとなる。拡張機能やChromeアプリを作るとき、ユーザに見える部分は単にHTML/CSS/JSでシンプルに作って、イベントハンドラからbackground pagesにメッセージを投げていろんな処理や拡張機能用のAPI呼び出しを一本化したり、といったことに使われてきた。

background pagesは便利だったんだけど、問題がひとつあった。というのは、拡張機能をインストールするとそのbackground pagesのプロセスがずーっと起動しっぱなしになってリソースを無駄遣いするのだ。そこで導入されたのがevent pagesで、ようするに「background pagesなんだけど、ブラウザは適当にプロセス止めてもいいっすよ」というフラグをつけたものと思えばいい。

event pagesはインストール時や初回起動時に実行され、イベントハンドラを登録する。そういうイベントが発生したときや、また拡張機能のUIからbackground pageにメッセージを投げようとすると、プロセスが起こってメッセージを処理し、しばらくするとプロセスが勝手に止まる。

Service workersは、このevent pagesをウェブ流にうまく表現したもの、ということができると思う。Chromeの場合、プロセスを適当なタイミングで閉じて、フェッチが発生したりページからpostMessageしたときだけプロセスが起こるというのもいっしょだ（よく知らないけど実装もけっこう流用できていると思う）。拡張機能を書いてて便利だったことがいろいろできるようになる。はずである。

Service workersの現状と今後

最初に書いたようにChromeでは40から使えるようになった（39でもコマンドラインフラグを指定すれば使えるようになっていたが、フラグフリップしたようだ）。ほかにサポートを表明しているのはFirefoxだが、こちらはフラグがないとまだ動かないらしい。Operaはよく知らないけど、なかみはBlinkなので対応は進むと思われる。それ以外のブラウザは対応を表明していない（Firefoxが支持しているというのは面白いところなんだけど……まあそういう深読みはここでは避ける）。

そういう状況なので、いますぐService workersを使わないとヤバイ、とか、もう準備万端なのでバリバリ使うべき、という話とは程遠い。が、Service workersはキャッシュやオフライン化をオプショナルに、つまり「できる環境でだけうれしい」程度の機能として提供しやすいという面がある。そういう面では、Chromeの安定版で使えるようになるあと数週間後には、触ってみてどんなもんなのか試してみるぐらいの価値はあると思う。

ただ仕様はまだドラフト段階なので、細部は変わる可能性はある。詳しくはgithubのissueにて熟知すべし。なのかな。

なお、Service workersの仕様は、それなりに長いんだけど、機能としては比較的シンプルだということに気づく。ようするに、基本的にはフェッチイベントを受け取ってキャッシュしたデータをサーブする、という機能に特化していてそれ以外の用途にはあんまり向いていない。ほかにもこんなことができたら面白そうなんだけど、という夢みたいな話はあまり入っていない。

たとえばサーバからプッシュ通信を受けつけることができるとしよう。Facebookで誰かがメッセージを送ったらサーバプッシュが届いて、それをservice workersが受けて、タブが開いてなくても通知が出せる、となったら、かなり夢が広がる気がする。Google calendarの通知とか、いいかげんタブ開いてなくても教えてほしい。そういうのはまさに拡張機能が受け持っていた機能だったけど、ブラウザごとに作るのは不毛すぎる。

ほかにも、拡張機能のevent pagesにはchrome.alarmsというAPIがあって、定期的に処理するようなイベントなんだけど、これもService workersには含まれていない。１分ごとにフェッチして変化があったらページに通知して……みたいなやつ。window.setIntervalがあればいいじゃん、て思うかもしれないけれど、それは普通のJSのAPIなのでプロセスが止まったら不都合が生じてしまう（コードの意味が変わってしまう）ため、プロセスを止められなくなる。別なAPIで対応してあげる必要がある。

実はこの辺も議論されている。プッシュ通知はpush APIという別なAPIが提案されているし、定期的にservice workerを起こすというのはbackground sync APIという仕様になるようだ。

というあたりの状況からすると、service workersはいわば導入編であって、これを軸にこれからいろんな面白機能が入ってくるのかなと期待している。そういう意味でもservice workersはいろいろ注目のAPIだと思う。

謝辞

このブログの記事、先週頭ぐらいに書いていたドラフトがあったのだが、いろいろあって完全に書き直してしまった。もとの文章と全然違っちゃったけどそちらにコメントや訂正をいただいた+Eiji Kitamuraと+Hiroki Nakagawaありがとうございました。むろん、間違いや勘違いの責任は向井にあります。

参考資料

1. Chrome 40 で今すぐ ServiceWorker を試す: http://qiita.com/kinu/items/2abd61b4390f9bbaffc9 
2. Service Workers spec: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/
3. Service workers samples: https://github.com/GoogleChrome/samples/tree/gh-pages/service-worker
4. AppCache: https://html.spec.whatwg.org/multipage/browsers.html#offline
5. Chrome extensions event pages: https://developer.chrome.com/extensions/event_pages
6. push API: https://w3c.github.io/push-api/
7. Background sync: https://github.com/slightlyoff/BackgroundSync/blob/master/explainer.md