#iOSDC で JavaScriptCore の話をしたりみんなと談笑したり。楽しい時間を過ごしてきました。

カンファレンス

東京練馬で開催された iOSDC Japan 2016 に参加して、自分の好きな JavaScriptCore の話をしたり、みんなとたっぷり談笑を楽しんできました。

発表時の質問で答えきれなかったところについても補足しています。

東京・練馬の Coconeriホール で に開催された iOSDC 2016 に参加してきました。

iOS 界隈としては日本初の大規模カンファレンスと言えるのでしょうか、具体的な参加者数は分からないのですけど、会場自体は 500 人くらい入れる場所で、実際に人がひしめきあってたのを見ると、それくらいの規模感のイベントだったみたいです。

勉強会は "楽しむことこそ、いちばん" と感じる自分にとっては、スピーチの楽しさももちろん、関西方面の友人とも、東京方面でもなかなかお会いできない友人とも、そしていつもお馴染みの友人とも、たくさんの人とお逢いできてたっぷりお話しできて、それがいちばん嬉しかったように思います。

こうやって、それぞれが自由な意思で会えて、のびのびとした心地で話ができる場所って貴重。そんな機会を作ってくれた iOSDC に何より感謝したい心地です。そして、会の中で談笑に付き合ってくれたみなさま、ありがとうございました。最初から最後まで、話したい人たちと山ほど話せて、とっても楽しかったです。

参加者として

まずは参加者の立場で iOSDC の思い出を綴ります。

公募＆選考

今回の iOSDC は登壇者を公募し、内容を以って当落するというのが自分には珍しくて、斬新なスタイルのように映りました。

最初はこれが、そこまで大きな事には感じてなかったのですけれど、２つ応募したうち、最終的にいちばん話したいと思っていた内容が落選した時のがっかりした気持ち、それに出逢った瞬間に、その事の大きさを実感できた思いでした。

ネットでもちらほら 本当はこっちを話したかった みたいな言葉が届いてきて、きっと当選した人も落選した人も、みんなもそんな気持ちを乗り越え、選ばれたトークに全力を注いで、きっと会本番を迎えたはず。そんな、それぞれの複雑な想いが交錯しながらまっすぐゴールへと向かうイベント、これが楽しくならないはずがない。そんな心地で当日を迎え、そしてとっても楽しく日程を終えることができました。

そして、終わって改めて思うのが、トークを見事に選んでいるなと思うところ。誰もが楽しめるように気を配られたバランスの良いテーマ配分、自分も本命とは違ったもうひとつの方を選んでもらえて良かったです。

応援システム

そして、面白かったのが選考における応援システム。

絶対ではないけれど、選考の指標になる投票が事前に行われていて、応募者全員の 話したい！ 想いに触れられたことも、期待度を育む良いシステムだったように思います。

そしてそれは同時に、投票すればもしかして 自分の聴きたい内容に iOSDC が傾いてくれるかもしれない ということ。それならばと、自分は投票するのと同時に Qiita に iOSDC で自分が聴きたいトーク！５選 を投稿して、聴きたいトークをみんなにアピールしてみたりしました。

選ぶこと自体も楽しかったし、そうして選んだトークの中から当日に２つも聴くことができて、とても幸せ心地です。

印象に残った発表

自分は当日 15:20 の発表枠を頂いていて、ぎりぎり近くまで準備に時間を費やしていたため、ほんとうにゆっくり聴くことができたのは、最初の 海外のiOSカンファレンスに登壇する と LT タイムの 最初 からだけでした。

どちらともすっごく聴きたくて、そこに照準を合わせて動いていたのもありますけれど、前者は朝いちばんだったから これを観てから本気だそう と思える余裕があったこと、後者は自分の登壇も終わってなんとか落ち着きを取り戻せたこと、そんなことが幸いして目的達成、ゆっくりとした心地で観られてホッとしました。

ほかにも、観たかった発表はいっぱいあって、それぞれの場所に行って声や姿を感じることはできたのですけど、発表資料のブラッシュアップに集中してたり、登壇直前のための待機や登壇後の整理で全部の時間を見られなかったり。

そんな感じでしたけど、聞きたかったスピーチの時間に居合わせることができて良かったなって思うのと、録画で見られるのが嬉しいです。そしてそんな慌ただしさも登壇の醍醐味、全体を通してとても楽しかったです。

ちなみにそんなふうにしながら自分が眺めたスピーチを、思い出として列挙しておこうと思います。

前夜祭

本会

懇親会

それと閉会後の懇親会は、たくさんの人と話せてほんとうに良かった。

途切れることなく、話したい人たちとたっぷり話に花を咲かせられる、とても幸せな時間でした。ほんとうに例外なく、会いたい人と会えて、ずっと一緒に話せてた心地。

こういう、たっぷり談笑に浸れる時間っていいですね。登壇者には前夜祭の後にも集まりがあって、たっぷりと楽しませて頂きました。せっかくのこういう時間、別チケット制ではなくて、本会のチケットに含めて全員が自由に参加できたらもっと楽しそうだったのになって思ってみたり。

登壇者として

そして、自分は今回 Swift で JavaScript 始めませんか というテーマで 15 分ほど、お話しさせて頂けたので、その立場から、反省点とか当日に説明しきれなかった技術的なところとか、綴ってみます。

大きなイベント、たくさんの公募の中からスピーカーとして選んでもらった感謝、いつもとってもお世話になっている人たちが関わって開催している会、楽しそうな参加者の顔、爽快感に溢れた Track A の会場内に居合わせたみんなから伝わってくる熱意がキラキラ輝いていて。

そういった空気に触れていたらワクワク感が止まらなくって、それに報いるためには最善を尽くさなくてはいけないみたいな思いが強く湧いてきて、ギリギリまで徹底的に準備して、すごく良い状態ではあったのですけど、逆にちょっと良すぎて勇みすぎてしまった感じ。話している最中、自分の勢いに自分自身が追いついていない心地がずっと拭えませんでした。もうちょっと余裕を持って、のんびりできたらよかったのにな。

なんにしても、みんなに自分の好きな JavaScriptCore を紹介できて楽しかった。

発表内容の補足

今回は JavaScriptCore の基本的な使い方に焦点を当てて、誰かがいつか 使ってみようかな って思ったときに、滞りなく Swift から JavaScriptCore を使えることを目標に内容を揃えてみました。

Swift で JavaScript 始めませんか？ #iOSDC from Tomohiro Kumagai

以前に書いた資料

その他にも JavaScript の例外を Swift 側でキャッチする仕組みが用意されていたりして、なかなか柔軟に扱えるのが魅力です。そんなあたりも含めたもう少し細かいお話を、かつて Swift 1.0 beta の頃に整理した資料があるので、そちらもお知らせしておきますね。

JavaScriptCore.framework の普通な使い方 #cocoa_kansai from Tomohiro Kumagai

反応の寄せ集め

そして、今回の発表中にみんながしてくれたツイートをまとめてもらえてました。

そんなふうにして今回の発表に対して幾つか反応を頂けたので、それについて紹介しておこうと思います。

アプリ審査を通るかについて

この肝心の話題、自分はさして気にしてなかったんですけど、当日に発表資料を精査している途中で JavaScript を使って、アプリの審査は通りますか？ という質問が出てくるだろうなと思ってしまい、さらには調べてみたら、何年も前の情報で JavaScriptCore をリンクしているとリジェクト みたいなのが出てきてしまって。

そんな事情でスライドに 急遽追加 したのでした。

JavaScriptCore を使うこと自体は問題なさそう

自分の中では、審査のガイドラインに書かれている 2.7 Apps that download code in any way or form will be rejected とも感じが少し違うような気もするんですよね。

今や Apple TV がサポートされているのを見るとなおさら、憶測は超えないながらも使える可能性を充分感じて、そのあたりを発表中に説明しようと思ったのですけど、ちょっと中途半端だったかもしれません。それに、ダウンロードして実行するだけが JavaScriptCore でもないですしね。

ともあれ、やっぱり関心の強いこのテーマ、発表終了直後の Q&A タイムに、たっぷり教えていただいたのですけど、実際に React Native でも JavaScriptCore が使われていて、審査が通る実績があるみたいで、ホッとしました。

そして自分もそのうちに、実際に審査を通してみようと思います。

JavaScriptCore の使い道

ところで、そんな発表が終わった後、何名かから 使い道がイメージできない みたいに話しかけてもらったので、その辺りについて少し補足してみますね。

ランタイムでの即時実行

まず JavaScript の何よりの特徴は ランタイムでテキストから即時実行できる というのが挙げられるかなと思います。JavaScriptCore を使うときには、この特徴からメリットを如何に引き出せるか、そんな軸で使いどころを考えてみると良いかもしれません。

ランタイムで実行できるということは、ランタイムでコードを組み立てて実行できる、リソースから読み込むというのも含めて。ということは、カスタムスクリプト環境をアプリ利用者に提供するのに向いていそう。

自作アプリでの使用例

たとえば、自分は自分専用で簡素なブログ作成ツールを作って、そこで JavaScriptCore を使っています。

そこでは記事を書くときに、次のような Markdown を少し拡張した書式で本文を書くようになっています。この中で出てくる ezclip:source-code みたいなのがキーワードになっていて、それが引数を受け取るようになっています。

次の内容は、そんな自作アプリで使う Markdown 書式の一例です。

クリップを作成したい時には、次のような XML ファイルを用意します。

 ```ezclip:source-code
 :language xml
 :filename 
 <?xml version="1.0" encoding="UTF-8"?>
 <clip version="1.0">
 </clip>
 ```
 
 そしてこの中で必要事項を定義してあげると、クリップとして使えるようになります。

これを HTML に変換するときに、上記であれば ezclip:source-code という識別子が添えられたブロックをどう HTML に変換するかを、所定のフォルダーに格納した XML ファイルに記載します。この変換ルールを表現するのに JavaScriptCore を使っています。

アプリの実装の方にあらかじめ変換用の API セットを用意しておいて、XML 内の buildRule タグで、変換方法を JavaScript で記載します。

<?xml version="1.0" encoding="UTF-8"?>
<clip version="1.0">
	<meta>
		<name>source-code</name>
	</meta>
	<buildRules>
		<buildRule target="website" language="javascript" tag="pre code">
		<![CDATA[
			var importOption = clip.getOption('import').trim();
			
			if (importOption.length > 0)
			{
				var resource = 'Resource/' + importOption;
				var lines = core.read(resource);
				
				return core.resolve(lines.join('\n'));
			}
			else
			{
				return core.resolve(clip.content);
			}
		]]>
		</buildRule>
	</buildRules>
</clip>

このファイルを所定のフォルダーに収めておけば、このルールに従って HTML を作ってくれます。もし やっぱり HTML の出力方法を変更したい みたいに思ったときには、この XML ファイルを書き換えるだけで調整できるようになる、みたいな感じです。

API と XML の仕様さえちゃんと決めて実装しておけば、XML ファイルを追加するだけで新しい挙動のキーワードをすぐに追加できる、みたいなことだって実現できます。

つまり、アプリをビルドできない人でもアプリの挙動を調整できる、けっこう便利な使い方のひとつかなって思います。

メモリ管理について

それと JavaScriptCore で Swift のオブジェクトを参照したときについて、質問をいただいて、的確な回答ができなかったので、それについても補足しておきます。

原則、強参照

まず、Swift は ARC で管理し、JavaScriptCore では Garbage Collection で管理することになるそうです。このとき、Swift で作成したネイティブインスタンスは、JavaScriptCore に渡したときに 強参照 で保持されるようです。

Swift は ARC によってスコープ単位で保持されますけど、JavaScriptCore では JSContext を管理する JSVirtualMachine に Garbage Collector によって保持されることになるようです。それ以降のメモリ管理はお任せで良いように思えましたが、Garbage Collection に慣れてないので、もしかすると違うのかもしれません。

JSManagedValue 型

そして Q&A のときに紹介した JSManagedValue についても少し調べてみました。

これは JavaScriptCore で使っているオブジェクトを Swift 側で weak で持ちたい ときに使うもののようです。JavaScriptCore から JSValue を受け取ったときに、それを Swift 側で weak 的に保持したいときに、次のように JSVirtualMachine の addManagedReference と一緒に使います。

// JSValue を JSManagedValue にラップして、プロパティ等に保持
value = JSManagedValue(value: context.objectForKeyedSubscript("value"))

// この JSManagedValue を JSVirtualMachine に登録する
context.virtualMachine.addManagedReference(value, withOwner: self)

このようにしてあげると Swift では弱参照として JSValue の値を持つことができ、JavaScriptCore 側でインスタンスが全て解放されると、Swift 側の JSManagedValue が持つ JSValue 型のプロパティ value の値が null に設定される様子でした。

JavaScriptCore と Swift との間で循環参照が発生するときに、それを解消するために JSManagedValue を使うことになるようです。つまり JavaScriptCore 側によってマネージされる弱参照のオブジェクト みたいに捉えておけば大丈夫そうです。

ECMA 2015 (ES6) 対応

たしか JavaScriptCore は Safari のコアエンジンとしても使われているものだと思うので、Q&A でも教えてもらったように使えるだろう、という認識でしたけど、それ以上のことは言えなかったので、実際に使って試してみました。

そうしたところ macOS 10.11 El Capitan の Safari 9.1.2 で ECMA 2015 二進数リテラル や class 定義 などの機能が使えることを確認できました。さらに macOS 10.12 Sierra の Safari 10.0 だと アロー関数による関数宣言 や 引数のディフォルト値指定 もできるようになっているようでした。

具体的な対応状況はきっと ECMAScript 6 compatibility table にまとめられている通りかもしれません。

iOSDC 楽しかった

そんな感じの iOSDC でしたけど、率直に、ものすごく楽しかったです。

いちばん印象に刻まれてるのは、本会の後の懇親会かな。なんだろう、なかなか会えない人たちも交えて話が弾んでいたからか、いつもの技術話とはちょっと違う話で盛り上がれたのがほんとうに楽しかった。それと同じくらいに記憶に残っているのは登壇、Track A でのあの期待の膨らむワクワク感はとても素敵な思い出です。

iOSDC Japan 2016 すっごく良かった。

参加者のみなさま、登壇者のみなさま、スポンサーさま、トーク選びに参加してくださったみなさま、運営スタッフのみなさま、実行委員会のみなさま、そして実行委員長の 長谷川 さま、素敵な機会をどうもありがとうございました。