Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2016年09月27日

SPAJAM決勝に参加しました

はじめましての方も、そうでない方も、こんにちは。フリューの佐藤こと、ジョンです。
遅くなりましたが、SPAJAM決勝戦に参加してきましたので、ご報告です。
予選については、こちらをご覧ください。SPAJAMについては、http://spajam.jp/をご覧ください。

予選から本戦にむけての準備

以前の予選を踏まえ、振り返ってその対応を試みました。

  • そもそもツールが使いこなせていなかった
    • 勉強するのにも時間が足りないため、使い慣れているツールに変更しました
  • アイデアが少し弱かった
    • 予めアプリの方向性を考えておく。今回はVRを使ったアプリにしていこうという方向性

果たしてこの方法が正しいことなのかは、さておき。
今度はディスプレイを持たず、新調してもらったMacBookをもって出発です。

本戦当日

会社の都合上、前日は金沢の旅館にいましたので、朝早く北陸新幹線で移動となりました。旅館から、旅館へ。温泉から、温泉へ。
向かう先は、埼玉県熊谷市ホテルヘリテイジ 四季の湯温泉です。
熊谷までつくとSPAJAM用の臨時バスが来ましたので、それに乗りました。

本戦会場は地下でした(高所恐怖症の方は安心です)

会場の雰囲気

荷物をとりあえず置いてから、別部屋に移動後、各チームの紹介、テーマ発表、アイデアソンという流れでした。
この辺りはニコニコ生放送でも放送されていたようです。
DSC_0817[1]

浴衣来てますが、すぐ脱ぎます。テレビ用ですね。
お昼もおいしく頂きました。ビールも提供されていました。ですが、流石にこの後二日間あると思うと飲めませんでした。

一日目の昼食
今回のテーマは「」でした。
予選よりも抽象度が高く、アイデアソンでのアイデア出しは、困難を極めました。

単純に音を鳴らす、ということではダメだろうという話はチームでも出ていましたが、打破する案も浮かばず。
ということで、前準備で考えていたVRを使った○○ということで、無理矢理にでも進めました。

各人の担当は、前回とほぼ同じくではありますが、今回はVRと言うことで、OpenGLを使ったプログラミングです。
行列の計算やシェーダの実装などを行いました。テーマに沿うように、音声認識もつかいました。

OLYMPUS DIGITAL CAMERA

目の前に温泉がありつつも黙々と作業をしていきます。
1日目の夕食、2日目の朝食、昼食……と食事はすべて用意されていたので、ありがたかったです。

予選と同様に、時間がないうちにどれだけ完成に近づけるか、プレゼンで発表される部分を意識して作成をしていきました。
そして、やはり予選と同様に、最終的には各自、自分の担当範囲だけではなく、今何が足りていないのか、時間が決まっているなかで、何ができて、何ができないのかを考え行動していけていました。

2日目の夜には、各チーム作成したアプリのプレゼンテーションをしました。その後、懇親会も踏まえ実際にアプリを触ってもらえる実演会が用意されていました。
同時に他チームの方との交流もでき、アプリも触ることができました。

他チームも、技術レベルが高くおもしろいアイデアのアプリを作られていました。もちろん、プレゼン途中でアプリが動かなかったりなどのハプニングもあり、同時にハッカソンの難しさを味わいました。

そして、時間が過ぎると、ハッカソンイベントの主要部は終了となります。

ようやく温泉にありつけました。部屋も用意されてあります。
ちなみに、温泉に入るタイミングは自由ですし、皆がアプリを必死で作成している間に温泉に入っても何も問題ありません。

成果物について

今回作成したアプリは、以下です。

logo01

音(歌)から広がる世界を楽しめるアプリというコンセプトで進めました。子供向けのVRという、将来的な展望も兼ねていました。
VRゴーグルは、Google Cardboard V2です(目はデザイナさんに描いてもらってます)。こちらを装着してVRの世界を見て回ります。

img_20160914_191945

始める前にまずBGMを選択します。

screenshot_20160914-172114

そうすると、そのBGMにあったVRの世界が表示されます。
スマートフォンには2つの画面が表示されますが、VRゴーグルを通すと2つの画面の差分により立体視ができます

screenshot_20160914-172727

技術的な部分としては、先ほど書きましたが3DCGを描画するためにOpenGLを使用しています。
他には、GoogleのCLOUD SPEECH APIを使っており、特定のキーワード(例えばリス、くま、など)に対して中の動物たちがリアクションを取ってくれたり、音楽が変わったりします。

結果

結果発表は、プレゼンテーションから夜が明けた3日目。会場を東京浅草にある HULIC HALLに移し行われました。
その前に、結果発表の前にドローンを使っての写真撮影をしました。すごかったです(詳しくは http://spajam.jp/final/result/ に動画がありますのでこちらを参照ください)。

本戦計12チームがありましたが、結果

ファイナリスト賞

を頂きました。大文字で書いておきながら、残念ながら、いわゆる参加賞です。

審査員の方から評価を聞いたところ、やはりアイデアでの点で弱かったようです。

ちなみに、最優秀賞は ちゅらゴンズさん の 音録(オドロク)でした。

感想

業務ではWebアプリケーションを触っており、スマートフォンのアプリ開発に携わることがありませんでした。
しかし、今回の予選から本戦までを体験でき、以下の知見を得ることができました。

  • 会社の中でも特に関わりが少ない人とのチームを組めた(大きな組織になってくるとなおさら!
  • 今までやったことのない技術を使う機会があった(特に本戦で使用した音声認識は個人的にはとても興味深く、業務にも活かせそう
  • 社外の方との交流を持てた(名刺は持って行きましょう!

以上いろいろありましたが、プラスしか無いです。(もちろん、疲れたとかはありますが
興味のある方は、次回SPAJAMに参加してみてください!

%e9%9b%86%e5%90%88%e5%86%99%e7%9c%9f


2016年05月18日

ハッカソン(SPAJAM)の大阪予選で最優秀賞をいただきました

初めまして、フリュー佐藤、こと、ジョンです。 安心してください、普通の日本人です。

普段は「ピクトリンク」のサイトの開発、運用しており、サーバサイドの開発を行っております。

今回はSPAJAM2016 大阪予選に参加したことを書きたいと思います

SPAJAM2016とは

http://spajam.jp/

スマートフォンアプリジャム2016、2日間でスマートフォンアプリを開発するハッカソンイベントです。

spajam6

全国で予選があり、本戦が温泉地で行われます。本戦には、各予選での最優秀賞の9組、各予選の優秀賞の中から2組、学生枠で1組が本戦に参加することができます。

SPAということで温泉に浸かり、頭をリフレッシュしながらの開発です。 素晴らしいですね。

本戦で優勝するとシリコンバレーツアーがプレゼントされます。 素晴らしいですね。

SPAJAMに参加する前準備

チームはプログラマ3人、デザイナー1人、プランナー1人という構成でした。 プログラマは業務で画像処理をメインにやっていた2人と、僕でした。

つまり、圧倒的なスマートフォンアプリ開発者不足。逆に言えば、これからどうやって開発していこうかと考える幅がありました。

……いや、正直言ってそんな暇はありませんでした。出場が決まってから当日までは2週間ほどです。

とりあえず手持ちの環境で、かつ、ネイティブアプリ作成ができそうなものということでAndroidのネイティブ開発にしました。Androidの開発は弊社でも行われていたため、その人達に教えてもらいながら勉強をしました。

全員ハッカソン自体にも出たことがないので、半日での模擬ハッカソンをしてみました。

ハッカソンの結果、様々な課題が見えてきました。

僕の方から、開発環境として以下のものを勧めてみました。

  • バージョン管理システム:Git

ブランチの切り替えが早い。また、githubを使うとレポジトリが無料で使えるのでcodeの共有も簡単。

  • 統合開発環境(IDE):Android Studio

Googleが提供しているIntelliJがベースとなっているIDE。弊社Android開発でも使用しているため、ノウハウはある。

  • Slack

無料で使えるコミュニケーションツール。チャットも使え、ファイルの共有もできる。また、Mac、Windows関係がなく使うことができる。

しかし、他のメンバーは、他の開発環境(svnやVisual Studioなど)を使っており、馴染みがなく、僕もきちんと説明している暇もなく、あまつさえAndroidに関しては僕も詳しくないので、お世辞にもスマートな開発ではありませんでした。

ハッカソンの結果を踏まえ、2週間ほどで得た付け焼き刃立派な知識の中で、結局このチームで何ができるのか、できないのかを考えました。

結果、ツールは触りながら覚え、それにプラスして、チームでのカラーを出せるように、画像処理を使ったアプリが開発出来るように環境を整えることで、本番を迎えようと決めました。

模擬ハッカソンはやっておいて本当に良かったです。本番で起こりえそうな問題(proxy、ソースコードの競合などの技術的問題から、プレゼンでの発表形式、画像の共有のしかたなどのハッカソンの進め方まで)について身をもって体感できたからです。

大きなディスプレイとmac miniをキャリーカーに詰めて出発です。(僕だけ

SPAJAM当日

予選会場はYahoo!JAPAN大阪でした。27階という高層。

spajam風景1

高所恐怖症の人はまずそれとの勝負(僕だけ

今回のテーマは、「おでかけを楽しむ」でした。

アイデアソンでは、たくさんのアイデアが出てきましたが、チーム内ではこれだというアイデアは出てきませんでした。15時まで考えつづけましたが結局はいいアイデアが出ず、当初の予定である画像処理を使ったアプリを考えるようにしました。

役割分担は以下です。

  • 僕: UIまわりの組み立て
  • プログラマ他二人: 画像処理部分を作成
  • プランナー: アプリの仕様、その見せ方
  • デザイナー: 発表資料やアプリに必要な画像の作成

UI周りについてもいろいろ考えたりしていました。

spajam2

時間がないうちにどれだけ完成に近づけるか、プレゼンで発表される部分を意識して作成をしていきました。

spajam7

最終的には各自、自分の担当範囲だけではなく、今何が足りていないのか、時間が決まっているなかで、何ができて、何ができないのかを考え行動していけていました。

成果物について

今回作成したアプリは以下です。

パシャ男

「お出かけを楽しむ」ため、お出かけ中にライブでアルバムを埋めていくアプリとなっています。

spajam4

レイアウトを決めて(プレゼンテーションの時は全部同じレイアウトでした。

Screenshot_2016-05-15-18-07-54

カメラアイコンをタップすると写真がとれます。また、動画を撮影することができます。

Screenshot_2016-05-15-18-08-04

しかし、パシャ男の本気はこれだけではありません。写真を取る際に通行人を消すことができるのです。

これがプレゼンテーションでは大きく反響を得られました。

結果

大阪予選計12チームがあり、僕達のチーム以外にも、他のチームのアプリもとても魅力的なものが多く、SPAJAMのレベルの高さを感じました。また、学生のスキルの高さにも驚かされました。

しかし、そんな中、僕達のチームはプレゼンテーションを完璧にこなすことができ、結果

最優秀賞

をいただくことができました。

OLYMPUS DIGITAL CAMERA

総評としては

  • 画像処理などの技術力が光っていた
  • アプリのUI部分で完成度が高かった
  • アイデアについては他の優秀賞とも比べると少し弱かった

とのことです。これを次の本戦で活かしていきたいです。

まとめ

ここまでで説明させていただいた通り、アプリ開発をやったことのないメンバでもアプリを開発することができました。また、アプリ開発においては秀でた知識は無いですが、それを他の知識でカバーして、最優秀賞をいただくことができました。

本戦は、7月2日(土)〜7月4日(月)です。それまで、今回受けた刺激や、面白いと思ったアイデアをどうやれば実現できるのかという部分まで落とし込んで、実装力を上げて行きたいと思います。

この記事を読んだ方で興味がある方、まだ、予選の応募ができる箇所がありますのでぜひ申し込んでみてください!


2016年03月3日

sakata

JavaOne 2015 サンフランシスコに参加しました!(3日目以降)

Hello World! コンテンツ・メディア第1事業部の、jyukutyoこと阪田です。JavaOneではランチボックスが配られるのですが、聞いていたほどおいしくないという感じではなかったです。味はイマイチだけど食べたくないほどではないな、という感じでした。外で食べるとなると確実に$20は超えてしまうので、私はほぼこのランチボックスを食べていました。

私はランチボックスの写真を撮っていなかったので、JavaOneのランチボックス写真をflickrからお借りしました(さくらばさんありがとうございます)。 2014年のものですが、2015年でも同じ感じでした。

Lunchbox, JavaOne 2014 San Francisco

Protecting Java Bytecode from Hackers with the InvokeDynamic Instruction

Javaのバイトコードは高レベルのJVM命令セットです。スタック指向であり、命令フォーマットがあります。

ラムダ式を使った以下のコードがあるとします。

これはバイトコードでは次のように表現されます。

Procyon(https://bitbucket.org/mstrobel/procyon/wiki/Java%20Decompiler)というでコンパイラを使って起動してみます。$java –jar procyon.jar HelloJavaOneWithLamdas.class出力は次のようになります。

Javaのバイトコードへの攻撃としてはリバースエンジニアリングや、重要なルーティンへのバイパス、デコンパイルと変更が容易であることなどです。有名なJavaのデコンパイラは次にようなものです。Procyon + LuytenやCFR、JD、Fernflower、Krakatau、Candleです。 Javaのバイトコード保護としては、コードフロー難読化や名前の難読化、呼び出しの隠蔽などです。ここでObfuscatorという製品をデモします。

次にコンスタントプールとバイトコードについて考えます。コンスタントプールはすべてのシンボル情報を含んでいます。invoke*という命令はメソッド呼び出しに使われます。JVMはメソッド実行の前にスタックが矛盾しないことを要求します。

リフレクションを使って呼び出しを隠蔽することができます。

そうすると、メリットとしてコンスタントプールからMethodRefとFieldRefを取り除けます。デメリットとしてはパフォーマンス、バイトコードサイズのオーバーヘッド、引数や戻り値でボクシング/アンボクシングが必要となること、スーパークラスのメソッドを呼び出せないこと、プライベートメソッドやフィールドへアクセスするときにセキュリティ違反になること、などがあります。

そこで、JSR-292のInvokeDynamicです。Java 7から導入されています。InvokeDynamicを使って呼び出しを隠蔽します。プランとしては、ブートストラップメソッドを生成し、invokevirtual/invokeinterface/invokestaticの呼び出しをinvokedynamicに書き換えます。それにはASMを使います。ASMは低レベルのバイトコード操作のためのライブラリです。SAXのようなVisitor APIとDOMのようなTree APIがあります。ASMでHello Worldすると次のようになります。

ソースコードを読み込み、ASMを使ったコードに書き換えるわけです。ブートストラップを生成するコードはこのようになります。

次に、invoke*の置き換えですが、MethodVisitorを実装します。

visitMethodInsn()メソッドは次のような実装となります。

結果として、たとえばJDででコンパイルするとエラーになります。他のデコンパイラでも読めません。結論としては、invoke*命令はすべて保護できました。さらにパフォーマンスのインパクトはありません。JVMがInvokeDynamicを最適化してくれます。

Having Fun with Javassist

JRebleなどを作っているZEROTURNAROUNDの方のセッション。 XRebelやJRebelでJavassistを多く活用しています。バイトコード操作はいたるところで行われています。Hibernateではプロキシ生成に使われています。主要なユースケースとして、バイトコード操作はJavaのフレームワークにおいてプロキシを生成するために使われています、がその内容だと退屈ですね。 JavassistはリフレクションAPIのような感じです。ClassPoolにCtClassがあり、CtClassにはCtFieldやCtMethod、CtConstがあります。CtMethodにはinsertBefore、insertAfter、instrumentがあります。

ビルド時にメタデータからクラスを生成できます。またはコンパイルしたクラスに対してあとから処理することができます。

こうして、トレーシングを実装したりログを追加したり、AOPを実装したりできます。不要な呼び出しを削除できます。フィールドに直接アクセスしていたところをsetter呼び出しに変えることができます。

次にJava Agentについて。$java –javaagent:agent.jar application.MainでAgentをつけて実行できます。Agentの実装はこうなります。

さらに、META‐INF/MANIFEST.MFにこう書きます。

ClassFileTransformerの実装としては、たとえばこんな感じです。

JRebleプラグインでもこの仕組みを使っています。JRebleプラグインでは、JRebleのコアとSpringやHibernate、EJBといった個別のプラグインがあります。jrebel.jarはすべてのプラグインを含んでいます。クラスをリロードすると、JRebleコアが各プラグインに通知します。そして、実際に設定が更新されたりします。Javassistは各プラグインで使っています。

Beyond top: Command-Line Monitoring on the JVM

サーバがたびたび遅くなる問題がありました。チームはアプリケーションサーバを手動で再起動していました。レスポンスタイムが5分ほどかかることがあありました。何かが起こっています。

事実に基づいてみると、すべてのリクエストが影響を受けていました。JVMは落ちていませんでした。JVMを再起動するとすべてがうまくいきました。何ができるのでしょう?さらなる事実として、フルGCが頻発していました。

ヒープに何があるか、どのアプリケーションコードを実行しているかを確認するために、いいツールがあります。まずvmstat。システムレベルでCPUやメモリ、ディスク、コンテキストスイッチが見れます。topも。プロセスごとのCPUとメモリが見れます。jpsでPIDがわかります。jstackでスレッドの状態がわかります。jcmdは何でもできます。jstatでGCやクラスローダ、コンパイラがわかります。

これで謎は解けます。たとえば、リークを除去する、キャッシュを除去する、機能を削除する、全文検索エンジン…”遅い”には意味がたくさんあります。”CPU負荷が高い”には意味がたくさんあります。データを集めることは危機的状況において極めて重要です。

ほかの役立つツールとしては、ヒープアナライザやプロファイラ、絶え間ないモニタリングやアラート、動的なトレースなどがあります。

Java Community Keynote

Javaコミュニティ(JUG)によるキーノート。これだけ別の大きな会場(Marriott Marquis)でした。

今回は、Java仕様に関わった人やJUGリーダなどが寸劇をするという衝撃的なものでした。ストーリは、JavaのマスコットであるDukeが、未来の世界で歯が生えて(!?)暴れまわっているため、世界を救うために過去にタイムスリップしながら破滅を避けるキーワードを探す、という内容でした。

キーノートのMCはStephen Chinさんで、去年私もJUGリーダとして少し話したことがあり親近感がありました。劇ではジェームズ・ゴスリン本人が登場したり、10年前くらいの世界で「Project Jigsawは完成しているんだろ!?(実際はJava 9なのでまだ)」という少し皮肉ったセリフが出たりと、とても楽しいものでした。

キーワード自体は”Kids are future(未来は子どもたちである)”というものでした。技術的な内容はまったくなく、純粋にJavaのお祭りを楽しむ、そういうセッションでした。

The Rise of 1.0: How Reactive Streams and Akka Streams Change the JVM Ecosystem

リアクティブ・ストリームのお話でした。リアクティブ・ストリームは.NET 3.5で導入されたのが最初です。その後、PlayフレームワークがIterateesを導入しました。AkkaはAkka-IOを、BenがRxJavaを開始しました。ただ2013年時点ではこの3つには違いがありました。Iterateesはpull back-pressureであり、APIが複雑です。Akka-IOはNACK back-pressureであり、低レベルIO、メッセージングAPIです。RxJavaはno back-pressureでいいAPIです。そこでエキスパートグループが創設されました。ゴールは、非同期で、ブロックせず、安全で、純粋に局所抽象化され、同期型も許容するということです。リアクティブ・ストリームには仕様とTCKがあります。バージョン1.0は2015/04/28にリリースされました。

なぜback-pressureなのか?負荷でクラッシュしないようにするためです。back-pressureとは何か? Publisher-Subscriberモデルで考えます。まず、Publisherのpushが早くてSubscriberが遅い場合、Subscriberにはバッファできる何かが必要です。でももしバッファがあふれたら?Subscriberはメッセージを捨てて、Publisherはメッセージを再送する必要があります。カーネルやルータはこうしています。メモリがあるときはバッファを増やせますが、いずれOutOfMemoryになります。Negative ACKnowledgementではバッファオーバーフローは差し迫ったものです。Publisherにペースを落とすか送信を停止してもらわなければなりません。しかしNACKではそれは間に合いません。そうしている間にもメッセージが来るからです。Publisherの速度よりSubscriberの速度が上回っているとき、back-pressureは必要ありません。

リアクティブ・ストリームは動的なPush/Pullです。pushだけでは遅いSubscriberのときに効果がなく、pullだけでは早いSubdcriberのときには遅すぎるのです。解決策としては動的な調整です。遅いSubscriberでは、3つの要素だけバッファに取ります。Publisherはたとえもっと多く遅れる場合でも多くて3つだけにします。これがpull-based-backpressureです。早いSubscriberはもっと要求します。Publisherは要求をためておきます。Publisherは各Subscriberの総要求数をためておき、オーバーフローしないように送ります。

Inter OPでは、異なる実装でもお互いにうまくやれるようにします。RxJavaとAkkaなど。リアクティブ・ストリームがプロトコルとなります。リアクティブ・ストリームはデイリーユースのエンドユーザAPIではありません。これはSPIです。Service Provider Interfaceです。SPIはサードパーティによって実装または拡張されることを意図したAPIです。

Play 2.5はAkka Streamsを使います。ScalaでもJavaでもDSLで同じパワーを得られます。Akka 2.4は2.3とバイナリ互換です。

カニパーティー

これはJavaOneとは直接関係がありませんが、JavaOneの日本人参加者で最終日の夜にカニを食べに行くというイベントが毎年あります。30名以上の方が来られていました。

IMG_1620

カニはダンジネスクラブというサンフランシスコでは有名なカニです。ガーリックソースでローストしており、日本では味わえないおいしさです。手はドロドロになりますので、汚れてもいい服の方がよいです。

話は自然とJavaのこと、いろいろな方と知り合うことができました!

JavaOne全体をふりかえって

最高でした!学べる内容としては、サンフランシスコまで行かなくてもプレゼンテーションの動画を見ても同じです。ただ、刺激という面では、やはり現地で受ける刺激はディスプレイの前で動画を見るよりも何十倍、何百倍も多いです。

英語のセッションということで心配になる方も多いかと思います。ふだん英語の技術文書を読まれている方なら、リスニングに不安があっても大丈夫です!スライドが補助となり、セッションが全部理解できないということはありません。迷うより飛び込んでしまうのが楽です!

私は今年もJavaOneに参加しようと計画しています。2016年のJavaOneは9/18〜22です。日本はちょうどシルバーウィークとなり、2日休暇を取るだけでJavaOneに参加できます!ぜひいっしょにJavaOneに参加しましょう!


2015年11月18日

morioka

関西モバイルアプリ研究会 #7を開催しました!

みなさん、こんにちは。ピクトリンクアプリを開発している盛岡です。

久方ぶりのブログ更新です。jyukutyoのサンフランシスコレポートの間に割り込んでみました。

今回のエントリは、先日フリューにて関西モバイルアプリ研究会#7を開催したので紹介したく書いてます。

関西モバイルアプリ研究会とは?

enter image description here

http://kanmoba.connpass.com/


関西モバイルアプリ研究会名のとおり、関西在住のエンジニアによるiOS/Androidアプリ開発者向けの勉強会です。

毎回コアなネタが繰り出される、おもしろい勉強会になっています。発表内容については上記URLの資料から参照出来ます。また、Twitterのハッシュタグ ‘#関モバ’ で検索してもらうと、雰囲気などがある程度伝わるのかなと思います。

毎月1回ペースで実施されており、今回は7回目でした。第8回目も予定されてます。

6回目までは株式会社はてなさんで実施していたのですが、7回目はフリューで開催することとなりました。

#7のトピックス

勉強会の進め方・発表形式は1人5分間のライトニングトークを、多めの人数(10人前後)で回していくというものです。

これが5分なのに深い内容が多い。第7回目は以下のような発表内容でした

  • Android6のセキュリティフレームワーク
  • iOSのA/Bテスト
  • Windows(Phone)のプッシュ通知処理
  • Retrofit2
  • instagram APIを利用したiOSアプリ開発
  • Google Cardboard
  • iOSのbitcodeについて
  • Fastlane
  • アプリの権利を委譲する

そうそうたる発表内容ですね。最新のiOS情報に関わるものからWindowsまで!

気になった発表

アプリの権利を委譲する話は興味深く聞かせてもらいました。

企業でアプリを作成していると、たまに話題になることがあります。が、仕様は頻繁に変わるみたいです。 発表者の方も「2015年10月時点での情報なので注意してください」と頻繁にアナウンスされてました。

また弊社でもFastlaneの導入を検討しており、実際の利用動向などチェックしていきたいなと感じました。

ちなみにFastlaneとは「Continuous Delivery for iOS Apps」を達成するためのプロジェクトになってます。

https://github.com/fastlane/fastlane

フリューで開催してみて

関西の凄腕エンジニアの方々との交流に一役かえるというのは、中々ない機会だと思います。実際に開催してみて凄く楽しかったですし貴重な体験でした。 発表内容を見てもらえればわかると思いますが、このような内容が聞ける会はそれほどないので是非継続していきたいですね。

事前準備等で不慣れな点がありご迷惑をおかけしたかと思いまが、京都タワー地下という立地条件は良かったという意見もあり、希望があれば会場提供も継続させてもらえればと思います。

今後も関西のモバイル開発を盛り上げていきましょう!


2015年11月16日

sakata

JavaOne 2015 サンフランシスコに参加しました!(2日目パート2)

Hello World! コンテンツ・メディア第1事業部の、jyukutyoこと阪田です。JavaOneは一番最初のセッションが始まるのは8:30、最後のセッションが終わるのは21:45です。お昼休みはありませんのでセッション間で昼食を済ませつつ、ずっとセッションを聴き続けるため、期間中はかなりハードです。観光などする時間はなく、お土産を買う時間を捻出するのもかなり大変でした。

Introduction to Modular Development

キーノートでもあった「Project Jigsaw」の紹介セッションです。構文はキーノートのレポートを参照してください。 今後java.lang.Objectなどはプラットフォームが提供するjava.baseモジュールにまとめられ、暗黙的に依存することとなります。モジュールのアクセシビリティは、モジュール内の公開されたパッケージのpublicなものだけです。公開されていないパッケージのpublicにはアクセスできないため、publicであるだけではアクセシビリティはありません。 モジュールはmodule-info.javaに記述し、コンパイルに含める必要があります。他のモジュールを使うときはjava -modulepath dir1:dir2のようにします。モジュールのmain()メソッドを実行するときはjava -m モジュール名/モジュールの完全修飾名で実行します。このあたりのことはProject Jigsawのクイックスタートページがわかりやすいです。-Xdiag:resolverオプションをつけると、依存関係の解決をログに出力することができるようです。

invokedynamic for Mere Mortals

JVM命令の1つであるinvokedynamic(indy)についてです。 JVMはもちろんJavaのために設計されたものですが、近年複数のプログラミング言語がJVM上で動作するようになりました。いまやどんな種類のプログラミング言語にとってもすばらしいプラットフォームとなっています。 Java以外の言語にとっての要求は、例えばcontinuationsやdyanmic invocation、tail recursion、interface injectionなどです。dyanmic invocation(動的呼び出し)をするために動的型付けがあるわけですが、動的型付けでは、呼び出しを実行するその瞬間までその型がいったい何なのか知ることができません。動的型付けは型妨害ではないし、弱い型付けでもありません。動的型付け言語は完全な型情報がなく、より実行時のチェックが求められます。indyができるまではこういった言語をJVMで動作させるためにはリフレクションを使うしかありませんでした。ただし、リフレクションにすると動作が遅く、引数がすべてObjectであったりとさまざまな問題がありました。リフレクションではインライン化できず最適化できませんでした。


JSR-292でjava.lang.invokeのAPIが追加されましたが、これはよりよいリフレクションと言えるかもしれません。そしてinvokedynamic命令が追加されました。これはリンケージのためにディスパッチするものです。indyはJVM命令セットができてから初めて追加された命令で、そして初めてJava以外の言語をターゲットにした命令です。メソッドハンドルとコールサイト、そしてブートストラップメソッド(bsm)という概念があります。メソッドハンドルはメソッドを指し示すものです。関数ポインタ的な考えでよいと思います。メソッドハンドルのパフォーマンスですが、リフレクションよりはかなり早くなります。indyとは独立して使うことができます。コールサイトがメソッドハンドルを使ってメソッド呼び出しをします。動的という意味では、コールサイトは変わらずメソッドハンドルを変えることで呼び出すメソッドを換えれられます。つまり、コールサイトがメソッドハンドルを保持しています。


次にブートストラップのステップです。indyを使ったコードを実行するとき、ブートストラップメソッド(bsm)を呼び出します。bsmはコールサイトを返すメソッドであるため、コールサイトを通じてメソッドハンドルへ、メソッドハンドルからメソッドを呼び出すというステップです。2回目以降の実行は、bsmは呼び出さずにコールサイトを通じて呼び出すだけです。リンケージは呼び出しではなく、リンケージは一度だけ実行する必要があるもので、またコストの高い処理でもあります。一方呼び出しは何度も実行するもので、jmp/callを必要とします。indyによってリンケージが変えました。java.lang.invokeのAPIはindyなしでもよく使われます。JVMはどの言語にとってもすばらしいプラットフォームと言えるでしょう。

Compact Strings: A Memory-Efficient Internal Representation for Strings

JEP(JDK Enhancement Proposals) 254: Compact Stringsについてです。Stringの内部表現でもっと効果的にリソースを使うようにしようというものです。個人的にはこれが2日目で一番興味深かったセッションですね。JDK9でのリリースが予定されています。 JavaはUTF-16をサポートしており、2バイト文字を使います。より効果的にリソースを使うようにしつつも、完全な後方互換性を保つようにします。どんな使用状況でも以前のスループットパフォーマンスは維持します。JDK6で失敗したCompressed Stringsの置き換えです。さまざまなアプリケーションから統計をとったところ、Stringの大部分は小さいもので、75%以上は35文字未満でした。また、x64でcompressd referenceを使わないと2倍メモリを使うことになります。


新しいStringクラスのデザインは次のようになります。後方互換性を維持しつつも、内部表現は変更します。UTF-16だけで表現するのではなく、 UTF-16またはISO-8859-1/Latin-1を使うようにします。1バイト文字はISO-8859-1/Latin-1で、2バイト文字はUTF-16とし、char配列ではなくbyte配列で表現するようにします。さらにencodingというbyteのフィールドを追加し、何のエンコーディングか示唆するようにします。なぜUTF-8ではないのかというと、UTF-8は文字幅が可変なためです。StringのAPIは文字シーケンスにランダムアクセスするものがたくさんあります。Stringクラスはこう変わるイメージです。JDK8ではStringクラスはこうでした。

JEP 254ではこうなります。

さきほどJDK6での失敗と言いましたが、具体的に見てみます。JDK6のCompressed Stringsがないときはこうでした。

Compressed Stringsでこうなりました。

valueがObjectであり、byte[]かchar[]かを判断する必要がありました。そのためCompressed StringsではStringクラスの2つの実装があることとなります。メンテナンスのコストもかかります。JREでのサポートに限界もありました。JEP 254ではbyte[]のみとなります。encodingフィールドも追加します。JREでcompressed stringsへのサポートも拡張できるでしょう。


JMH(Javaのマイクロベンチマークツール)でのベンチマークでは、すべてのケースで処理が早くなっています。メモリ使用量は21%削減できました。スループットも5%増加してよくなっています。

jyukutyoコメント

2日目に出たセッションからいくつかをピックアップしてレポートしました。これでまだ2日目!あと3日分あります。長いレポートになりますが、ぜひ最後までお付き合いください。